Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

From: Greg Mirsky <[email-masked]>
Date: Fri, 2 Aug 2019 13:00:31 -0400

Hi Rakesh,
thank you for your helpful comments. We've updated the format of the base
STAMP test packet. Appreciate your feedback on the proposed changes,
comments and questions,

Regards,
Greg

On Tue, Jul 9, 2019 at 9:27 AM Rakesh Gandhi <[email-masked]> wrote:

> Hi Greg,
> Regarding the size of the padding, yes, it's good to use the same size
> payload for query and response.
> However, the STAMP payload with TLV extension
> (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size
> (27 ( or > 29) vs. 30). Is there a way to make them compatible? Does it
> mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0
> for all 30 bytes. If the responder supports Server Octets and see the size
> > 27, it may find the Server Octet size of 0 confusing?
>
> Thanks,
> Rakesh
>
>
>
>
>
> On Mon, Jul 8, 2019 at 7:20 PM Greg Mirsky <[email-masked]> wrote:
>
>> Hi Shahram,
>> thank you for the review and questions. Please find my answers below
>> tagged GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <
>> [email-masked]> wrote:
>>
>>> HI Greg
>>>
>>> I read your draft and have the following questions:
>>>
>>> 1) Does it require any UDP/TCP port number or it reuses the one from
>>> TWAMP? if it reuses from TWAMP then  how does the receiver differentiate
>>> between TWAMP and STAMP?
>>>
>> GIM>> STAMP uses the well-known UDP port number allocated for the
>> OWAMP-Test/TWAMP-Test Receiver port (RFC 8545) as the default destination
>> UDP port number.. STAMP may use destination UDP port number from the
>> Dynamic and/or Private Ports range 49152-65535.
>>
>>> 2) What is the benefit of STAMO compared to TWAMP?
>>>
>> GIM>> The work was driven by several observations, among them:
>>
>>    - challenges in achieving interoperability among implementations of
>>    TWAMP-Light;
>>    - industry interest in standardizing performance monitoring in IP
>>    broadband access networks (TR-390);
>>    - improve extensibility of IP performance monitoring tool to support
>>    measurements, testing of new metrics and parameters, e.g., consistency of
>>    CoS in the network.
>>
>> 3) Why is there so much MBZ byte?
>>>
>> GIM>> It was agreed to make the symmetrical size of STAMP test packets
>> the default. RFC 6038 defined it for TWAMP and TR-390 requires it to be
>> supported by TWAMP-Light implementations.
>>
>>>
>>> Thx
>>> Shahram
>>>
>>> On Jul 8, 2019, at 10:17 AM, Greg Mirsky <[email-masked]> wrote:
>>>
>>> Hi Mirja,
>>> thank you for the suggested text. The new paragraph now reads as:
>>>       Load of STAMP test packets offered to a network MUST be carefully
>>>       estimated, and the possible impact on the existing services MUST
>>>       be thoroughly analyzed before launching the test session.
>>>       [RFC8085] section 3.1.5 provides guidance on handling network load
>>>       for UDP-based protocol.  While the characteristic of test traffic
>>>       depends on the test objective, it is highly recommended to stay in
>>>       the limits as provided in [RFC8085].
>>>
>>> If it is acceptable, I'd like to upload the updated version of
>>> draft-ieff-ippm-stamp before the cut-off deadline.
>>>
>>> Regards,
>>> Greg
>>>
>>> On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <[email-masked]>
>>> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> See below.
>>>>
>>>> > On 8. Jul 2019, at 16:54, Greg Mirsky <[email-masked]> wrote:
>>>> >
>>>> > Hi Mirja,
>>>> > thank you for the reference to RFC 8085. I agree that the document is
>>>> very much relevant and a reference to RFC 8085 in STAMP is useful. While
>>>> reading Section 3.1.3 I came to think that the discussion and guidance in
>>>> other sections of RFC 8085, particularly, Section 3.1.5 Implications of RTT
>>>> and Loss Measurements on Congestion Control. Would adding the reference to
>>>> that section in the new text proposed for the Security Considerations
>>>> section work? I'll put RFC 8085 as Informational reference as it is BCP.
>>>> > NEW TEXT:
>>>> >       Load of STAMP test packets offered to a network MUST be
>>>> carefully
>>>> >       estimated, and the possible impact on the existing services MUST
>>>> >       be thoroughly analyzed using [RFC8085] and its Section 3.1.5 in
>>>> >       particular before launching the test session...
>>>>
>>>>
>>>> Not sure if “using” is the right word but otherwise fine for me. Or you
>>>> could have a separate sentence like:
>>>>
>>>> “RFC8085 section 3.1.5 provides guidance on handling network load for
>>>> UDP-based protocol. While the characteristic of test traffic depends on the
>>>> test objective, it is highly recommended to say in the limits as provided
>>>> in RFC8085.”
>>>>
>>>> Or something similar…
>>>>
>>>> BCP is the same maturity level as PS. So it wouldn’t be a downref.
>>>> However, I think having this as informational ref is fine.
>>>>
>>>> Mirja
>>>>
>>>>
>>>>
>>>> >
>>>> > Regards,
>>>> > Greg
>>>> >
>>>> > On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <[email-masked]>
>>>> wrote:
>>>> > Hi Greg,
>>>> >
>>>> > Thanks a lot for you reply. Changes are good. I wonder if it would be
>>>> useful to provide a reference to RFC8085 because it has a lot of
>>>> information about congestion control of UDP based traffic? It recommends to
>>>> send not more than 1 packet per 3 seconds (if RTT is unknown). I guess it
>>>> doesn’t make sense to require this for testing traffic, however, it could
>>>> maybe still be a good recommendation? What do you think?
>>>> >
>>>> > Also I’ve just resend my review to the IPPM list, as I unfortunately
>>>> cc’ed only the IPPM chairs instead of the whole list. Can you resend you
>>>> proposed changes to the list, so other people are aware of these changes.
>>>> Sorry for the unconvience.
>>>> >
>>>> > Mirja
>>>> >
>>>> >
>>>> > > On 6. Jul 2019, at 17:46, Greg Mirsky <[email-masked]>
>>>> wrote:
>>>> > >
>>>> > > Hi Mirja,
>>>> > > thank you for your thorough review, very pointed and helpful
>>>> comments. Please find my responses in-lined and tagged GIM>>. Attached the
>>>> diff.
>>>> > >
>>>> > > Regards,
>>>> > > Greg
>>>> > >
>>>> > > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <
>>>> [email-masked]> wrote:
>>>> > > Hi authors, hi all,
>>>> > >
>>>> > > Thanks for this well-written document and very good shepherd
>>>> write-up! I would like discuss one point before I start IETF last call.
>>>> > >
>>>> > > I believe this document should say something about network load and
>>>> congestion (control). OWAMP and TWAMP discuss quite a bit sender
>>>> scheduling, however, as this is a simplified version, so I think it could
>>>> at least be good to put a waring in this document that packet sending
>>>> should be somehow rate limited. I know it might be hard to provide more
>>>> concrete guidance but at least having some discussion or warning in this
>>>> document could be good.
>>>> > > GIM>>  Thank you for your suggestion. Security Considerations
>>>> section points to the fact that STAMP does not include control and
>>>> management components:
>>>> > >    Because of the control
>>>> > >    and management of a STAMP test being outside the scope of this
>>>> > >    specification only the more general requirement is set:
>>>> > > adding the new text here:
>>>> > >       Load of STAMP test packets offered to a network MUST be
>>>> carefully
>>>> > >       estimated, and the possible impact on the existing services
>>>> MUST
>>>> > >       be thoroughly analyzed before launching the test session.
>>>> > >
>>>> > >
>>>> > > Another comment: You only say at the very end that a certain UDP
>>>> port is used, which implies that STAMP runs over UDP. However, I think you
>>>> should mention at the very beginning that this is a UDP-based protocol.
>>>> Just to make things crystal clear.
>>>> > > GIM>> Adding the reference to "UDP transport" into the first
>>>> sentence of Theory of  Operations section:
>>>> > >    STAMP Session-Sender transmits test packets over UDP transport
>>>> toward STAMP Session-Reflector.
>>>> > >
>>>> > > Mirja
>>>> > >
>>>> > > P.S.:
>>>> > > Nit: s/This document defines active performance measurement test
>>>> protocol/ This document defines an active performance measurement test
>>>> protocol/
>>>> > > -> “an” missing
>>>> > > GIM>> Thank you. Done.
>>>> > > <Diff_ draft-ietf-ippm-stamp-06.txt -
>>>> draft-ietf-ippm-stamp-07...txt.html>
>>>> >
>>>>
>>>> _______________________________________________
>>> ippm mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>>>
>>> _______________________________________________
>> ippm mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>

---

From: Rakesh Gandhi <[email-masked]>
Date: Fri, 2 Aug 2019 13:53:00 -0400

Thanks Greg for considering my review comments. Good to see the message
format aligned with draft-ietf-ippm-stamp-option-tlv and using MBZ 30. This
should fix the interoperability issue between the two. This also gives few
(3) bytes for any future extensions.

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

You may fix the spelling of my name and another typo below:

OLD:

and Rakesh Gandi or their

NEW:

and Rakesh Gandhi for their

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

I did not see following comment addressed. Is that intentional?

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

On Tue, Jul 9, 2019 at 9:11 AM Rakesh Gandhi <[email-masked]> wrote:

    Thanks Greg for the reply.

    In this case, should the draft just state that the Session-Sender can
select destination UDP port number following the guidelines specified in
[RFC6335], instead of specifying following?

Section 4.4

    Thus STAMP Session-Sender MUST be able to send test

       packets to destination UDP port number from the Dynamic and/or

       Private Ports range 49152-65535, test management system should find a

       port number that both devices can use.

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

Thanks,
Rakesh

On Fri, Aug 2, 2019 at 1:00 PM Greg Mirsky <[email-masked]> wrote:

>>>>> > thank you for the reference to RFC 8085. I agree that the document
>>>>> is very much relevant and a reference to RFC 8085 in STAMP is useful. While
>>>>> Not sure if “using” is the right word but otherwise fine for me. Or
>>>>> you could have a separate sentence like:
>>>>>
>>>>> > Thanks a lot for you reply. Changes are good. I wonder if it would
>>>>> be useful to provide a reference to RFC8085 because it has a lot of
>>>>> > > I believe this document should say something about network load
>>>>> and congestion (control). OWAMP and TWAMP discuss quite a bit sender

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 3 Aug 2019 10:04:53 -0700

Hi Rakesh,
my apologies for the misspelling of your name.
Thank you for your kind consideration of the proposed update.
Regarding the definition of the range of the valid UDP port numbers,
draft-ietf-ippm-twamp-yang
<https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> uses type
dynamic-port-number as follows:
     typedef dynamic-port-number {
       type inet:port-number {
         range 49152..65535;
       }
       description "Dynamic range for port numbers.";
     }
to specify the valid range for a sender-udp-port. The range for a UDP port
number of a Session-Reflector has been specified slightly differently
because it includes the well-known port 862:
           leaf reflector-udp-port {
             type inet:port-number {
               range "862 | 49152..65535";
               }
             description
               "The destination UDP port number used in the
                TWAMP-Test (UDP) test packets belonging to this
                test session.";
           }
But, as we observe, in both cases definitions include the Dynamic/Private
range explicitly defined. I think that keeping STAMP specification
consistent with the TWAMP, TWAMP YANG data model in particular, in the way
the valid range of UDP ports is being specified, is beneficial to the STAMP
document. Hope you'll agree.

Regards,
Greg

On Fri, Aug 2, 2019 at 10:53 AM Rakesh Gandhi <[email-masked]>
wrote:

>>>>    - improve extensibility of IP performance monitoring tool to
>>>>    support measurements, testing of new metrics and parameters, e.g.,
>>>>    consistency of CoS in the network.
>>>>
>>>>>> > On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <
>>>>>> > Also I’ve just resend my review to the IPPM list, as I
>>>>>> unfortunately cc’ed only the IPPM chairs instead of the whole list. Can you
>>>>>> resend you proposed changes to the list, so other people are aware of these
>>>>>> changes. Sorry for the unconvience.
>>>>>> >
>>>>>> > Mirja
>>>>>> >
>>>>>> >

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 6 Aug 2019 10:56:57 -0400

Hi Greg,

Many thanks for the reply.

As there are already implementations out there where such restrictions do
not exist as discussed in another email thread (just forwarded them), the
following text with MUST is already violated. The TWAMP Yang model
draft-ietf-ippm-twamp-yang
<https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> should also not
place such restriction.

Section 4.4

Thanks,
Rakesh

On Sat, Aug 3, 2019 at 1:05 PM Greg Mirsky <[email-masked]> wrote:

>>     In this case, should the draft just state that the Session-Sender
>> can select destination UDP port number following the guidelines specified
>> in [RFC6335], instead of specifying following?
>>
>>
>>
>> Section 4.4
>>
>>> thank you for your helpful comments. We've updated the format of the
>>> base STAMP test packet. Appreciate your feedback on the proposed changes,
>>> comments and questions,
>>>
>>> Regards,
>>> Greg
>>>
>>>>>    - challenges in achieving interoperability among implementations
>>>>>    of TWAMP-Light;
>>>>>>> “RFC8085 section 3.1.5 provides guidance on handling network load
>>>>>>> for UDP-based protocol. While the characteristic of test traffic depends on
>>>>>>> the test objective, it is highly recommended to say in the limits as
>>>>>>> provided in RFC8085.”
>>>>>>>
>>>>>>> Or something similar…
>>>>>>>
>>>>>>> > >    STAMP Session-Sender transmits test packets over UDP
>>>>>>> transport toward STAMP Session-Reflector.
>>>>>>> > >
>>>>>>> > > Mirja
>>>>>>> > >
>>>>>>> > > P.S.:

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 6 Aug 2019 11:06:04 -0400

Hi Greg,
Couple of additional comments on the draft:
There are TWAMP extensions for Checksum complement in RFC 7820 and DSCP-ECN
in RFC 7750. Good to add some text for STAMP if they can be supported or
not supported. I can see they can be supported as following, and should not
break anything:

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        Sequence Number                        |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                        Transmit Timestamp                     |

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|         Error Estimate        |           MBZ                 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                      Receive Timestamp                        |

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                      Sender Sequence Number                   |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|                      Sender Timestamp                         |

|                                                               |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|      Sender Error Estimate    |           MBZ                 |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|  Sender TTL   | S-DSCP-ECN    | Checksum Complement           |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,
Rakesh

On Mon, Jul 8, 2019 at 10:07 PM Greg Mirsky <[email-masked]> wrote:

> Hi Rakesh,
> thank you for your question. In my experience, some implementations of
> TWAMP-Light have taken the liberty to allow using UDP port numbers outside
> the Dynamic/Private range. I believe that is not the right decision. In the
> note of IANA's Service Name and Transport Protocol Port Number Registry we
> read:
>
>  Service names and port numbers are used to distinguish between different
>  services that run over transport protocols such as TCP, UDP, DCCP, and
>  SCTP.
>
>  Service names are assigned on a first-come, first-served process, as
>  documented in [RFC6335].
>
>  Port numbers are assigned in various ways, based on three ranges: System
>  Ports (0-1023), User Ports (1024-49151), and the Dynamic and/or Private
>  Ports (49152-65535); the difference uses of these ranges is described in
>  [RFC6335]. According to Section 8.1.2 of [RFC6335], System Ports are
>  assigned by the "IETF Review" or "IESG Approval" procedures described in
>  [RFC8126]. User Ports are assigned by IANA using the "IETF Review"
> process,
>  the "IESG Approval" process, or the "Expert Review" process, as per
>  [RFC6335]. Dynamic Ports are not assigned.
>
>  The registration procedures for service names and port numbers are
>  described in [RFC6335].
>
>  Assigned ports both System and User ports SHOULD NOT be used without
>  or prior to IANA registration.
>
> My interpretation is that ports in System and User ranges, even if not yet
> assigned, must not be used without following the assignment process. Thus,
> regardless of whether a number had not yet been assigned to a service, it
> must not be used as the destination UDP port number. Also, consider
> operational issues if a new service is assigned a new port number from the
> User Ports range. One day the number was "free" and tomorrow it may be
> assigned. Handling such a scenario will add complexity while benefits are,
> in my opinion, questionable.
>
> Regards,
> Greg
>
> On Mon, Jul 8, 2019 at 5:09 PM Rakesh Gandhi <[email-masked]>
> wrote:
>
>> Hi Greg,
>>
>> Why limit the UDP port range to 49152-65535? Any free UDP port can be
>> used, no?
>>
>> Thanks,
>> Rakesh
>>
>>

---

From: Henrik Nydell <[email-masked]>
Date: Tue, 6 Aug 2019 17:19:25 +0200

There is a distinction between "must be able to send to these destination
ports" and "must only be able to send to these destination ports"

The first wording does not prohibit senders to be able to send also to
other destination ports.

On Tue, Aug 6, 2019 at 4:57 PM Rakesh Gandhi <[email-masked]> wrote:

> <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> should also
> not place such restriction.
>
> Section 4.4
>
>> to specify the valid range for a sender-udp-port. The range for a UDP
>> port number of a Session-Reflector has been specified slightly differently
>>>>>> GIM>> It was agreed to make the symmetrical size of STAMP test
>>>>>> packets the default. RFC 6038 defined it for TWAMP and TR-390 requires it
>>>>>> to be supported by TWAMP-Light implementations.
>>>>>>
>>>>>>>
>>>>>>> Thx
>>>>>>> Shahram
>>>>>>>
>>>>>>>> > thank you for the reference to RFC 8085. I agree that the
>>>>>>>> document is very much relevant and a reference to RFC 8085 in STAMP is
>>>>>>>> useful. While reading Section 3.1.3 I came to think that the discussion and
>>>>>>>> guidance in other sections of RFC 8085, particularly, Section 3.1.5
>>>>>>>> Implications of RTT and Loss Measurements on Congestion Control. Would
>>>>>>>> adding the reference to that section in the new text proposed for the
>>>>>>>> Security Considerations section work? I'll put RFC 8085 as Informational
>>>>>>>> reference as it is BCP.
>>>>>>>> > NEW TEXT:
>>>>>>>> > Thanks a lot for you reply. Changes are good. I wonder if it
>>>>>>>> would be useful to provide a reference to RFC8085 because it has a lot of
>>>>>>>> > > Another comment: You only say at the very end that a certain
>>>>>>>> UDP port is used, which implies that STAMP runs over UDP. However, I think
>>>>>>>> you should mention at the very beginning that this is a UDP-based protocol.
>>>>>>>> > > Nit: s/This document defines active performance measurement
>>>>>>>> test protocol/ This document defines an active performance measurement test
>>>>>>>> protocol/
>>>>>>>> > > -> “an” missing
>>>>>>>> > > GIM>> Thank you. Done.

-- 

*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, 6 Aug 2019 09:14:28 -0700

Hi Rakesh,
thank you for pointing to these two RFCs. Please consider my thoughts:

   - RFC 7820 is Experimental and, as I understand, the proposed solution
   is not seen kindly by the security experts, and for a good reason. As
   you've correctly pointed out, STAMP in unauthenticated mode may easily
   support the technique described in RFC 7820. But I'm not sure we have to do
   that in the base specification. What we can do is to relax language on MBZ
   and drop "MUST be zeroed on transmission" leaving "MUST be ignored on
   receipt". What do you think?
   - I appreciate your interest in RFC 7750 (as one of co-authors). We've
   decided to support this functionality in an extension to STAMP. Class of
   Service TLV fully supports the functionality defined in RFC 7750 and offers
   the ability to instruct the Session-Reflector which DSCP value it must use
   for the reflected STAMP packet. Thus CoS marking consistency is verified in
   forward and reverse directions.

Best regards,
Greg

On Tue, Aug 6, 2019 at 8:06 AM Rakesh Gandhi <[email-masked]> wrote:

> There are TWAMP extensions for Checksum complement in RFC 7820 and
> DSCP-ECN in RFC 7750. Good to add some text for STAMP if they can be
> supported or not supported. I can see they can be supported as following,
> and should not break anything:
>
> 0                   1                   2                   3
>
>> My interpretation is that ports in System and User ranges, even if not
>> yet assigned, must not be used without following the assignment process.
>> Thus, regardless of whether a number had not yet been assigned to a
>> service, it must not be used as the destination UDP port number. Also,
>> consider operational issues if a new service is assigned a new port number
>> from the User Ports range. One day the number was "free" and tomorrow it
>> may be assigned. Handling such a scenario will add complexity while
>> benefits are, in my opinion, questionable.
>>
>> Regards,
>> Greg
>>

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 6 Aug 2019 14:06:48 -0400

Thanks Henrik. Where does this requirement come from? Also, how do I
configure the UDP port outside the range using the TWAMP Yang model?

Thanks,
Rakesh

On Tue, Aug 6, 2019 at 11:19 AM Henrik Nydell <[email-masked]> wrote:

>>> But, as we observe, in both cases definitions include the
>>> Dynamic/Private range explicitly defined. I think that keeping STAMP
>>> specification consistent with the TWAMP, TWAMP YANG data model in
>>> particular, in the way the valid range of UDP ports is being specified, is
>>> beneficial to the STAMP document. Hope you'll agree.
>>>
>>> Regards,
>>> Greg
>>>
>>>> Thanks Greg for considering my review comments. Good to see the
>>>> message format aligned with draft-ietf-ippm-stamp-option-tlv and using MBZ
>>>> 30. This should fix the interoperability issue between the two. This also
>>>> gives few (3) bytes for any future extensions.
>>>>
>>>>>> Regarding the size of the padding, yes, it's good to use the same
>>>>>> size payload for query and response.
>>>>>>>> 1) Does it require any UDP/TCP port number or it reuses the one
>>>>>>>> from TWAMP? if it reuses from TWAMP then  how does the receiver
>>>>>>>> differentiate between TWAMP and STAMP?
>>>>>>>>
>>>>>>>    - industry interest in standardizing performance monitoring in
>>>>>>>    IP broadband access networks (TR-390);
>>>>>>>> On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <
>>>>>>>>> Not sure if “using” is the right word but otherwise fine for me.
>>>>>>>>> Or you could have a separate sentence like:
>>>>>>>>>
>>>>>>>>> > > I believe this document should say something about network
>>>>>>>>> load and congestion (control). OWAMP and TWAMP discuss quite a bit sender
> 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: Rakesh Gandhi <[email-masked]>
Date: Tue, 6 Aug 2019 14:14:53 -0400

Hi Greg,
Thanks for your reply. Please see inline <RG>..

On Tue, Aug 6, 2019 at 12:14 PM Greg Mirsky <[email-masked]> wrote:

> <RG> Ok with that.

> <RG> In that case, draft may say RFC7750 method is not supported by STAMP?
Also, I think the draft dropped supporting the server octet [RFC6038],
right? If so, following text needs updating?
   o  Packet Padding (reflected) is an optional variable length field.
      The length of the Packet Padding (reflected) field MUST be equal
      to the value of the Server Octets field (Figure 2).  If the value
      is non-zero, the Session-Reflector MUST copy number of octets
      equal to the value of Server Octets field starting with the Server
      Octets field.

Thanks,
Rakesh

Best regards,

---

From: Henrik Nydell <[email-masked]>
Date: Wed, 7 Aug 2019 10:30:21 +0200

The range probably comes from the IANA definition of the ephemeral ports
(49152 to 65535) although these are defined for short-lived TCP and not
explicitly for UDP. Why this made it into the yang model for TWAMP-test
(which is UDP) I dont know, probably someone mixed it up with TCP and it
passed the reviewers without much thought.

Most, if not all, implementations of TWAMP I have seen does not impose
limitations on the source UDP ports for the TWAMP-test packets when
configuring via CLI. For example neither Accedian, Exfo, Viavi, Juniper,
Nokia, Huawei impose any limitation like that when configuring via CLI or
GUI.

With a yang model based configuration the user will of course be limited if
they use the yang model that only defines the ephemeral range as valid. I
see no severe disadvantages of this, but it would of course have been
better if the yang model was less restrictive, since the restriction has no
real value in itself.

On Tue, Aug 6, 2019 at 8:07 PM Rakesh Gandhi <[email-masked]> wrote:

>>> As there are already implementations out there where such restrictions
>>> do not exist as discussed in another email thread (just forwarded them),
>>> the following text with MUST is already violated. The TWAMP Yang model
>>>>>>>> thank you for the review and questions. Please find my answers
>>>>>>>> below tagged GIM>>.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Greg
>>>>>>>>
>>>>>>>>    - challenges in achieving interoperability among
>>>>>>>>    implementations of TWAMP-Light;
>>>>>>>>>> BCP is the same maturity level as PS. So it wouldn’t be a
>>>>>>>>>> downref. However, I think having this as informational ref is fine.
>>>>>>>>>>
>>>>>>>>>> Mirja
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> >
>>>>>>>>>> > Regards,
>>>>>>>>>> > Greg
>>>>>>>>>> >
>> 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

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Rakesh Gandhi <[email-masked]>
Date: Wed, 7 Aug 2019 08:55:45 -0400

Thanks Henrik.
Adding the authors of the TWAMP Yang model to see if they have any thoughts
on the UDP port range. It is still not an RFC, so may be this comment can
be addressed if needed.
Thanks,
Rakesh

On Wed, Aug 7, 2019 at 4:30 AM Henrik Nydell <[email-masked]> wrote:

> With a yang model based configuration the user will of course be limited
> if they use the yang model that only defines the ephemeral range as valid.
> I see no severe disadvantages of this, but it would of course have been
>>> There is a distinction between "must be able to send to these
>>> destination ports" and "must only be able to send to these destination
>>> ports"
>>>
>>>> <https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> should
>>>> also not place such restriction.
>>>>
>>>> Section 4.4
>>>>
>>>>>>     In this case, should the draft just state that the
>>>>>> Session-Sender can select destination UDP port number following the
>>>>>> guidelines specified in [RFC6335], instead of specifying following?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Section 4.4
>>>>>>
>>>>>>>>>>> “RFC8085 section 3.1.5 provides guidance on handling network
>>>>>>>>>>> load for UDP-based protocol. While the characteristic of test traffic
>>>>>>>>>>> depends on the test objective, it is highly recommended to say in the
>>>>>>>>>>> limits as provided in RFC8085.”
>>>>>>>>>>>
>>>>>>>>>>> Or something similar…
>>>>>>>>>>>
>>>>>>>>>>> > > GIM>>  Thank you for your suggestion. Security
>>>>>>>>>>> Considerations section points to the fact that STAMP does not include
>>>>>>>>>>> control and management components:
>>>>>>>>>>> > >    Because of the control

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 7 Aug 2019 14:28:49 +0000

From: ippm [mailto:[email-masked]] On Behalf Of Henrik Nydell
Sent: Wednesday, August 7, 2019 4:30 AM
To: Rakesh Gandhi <[email-masked]>
Cc: IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>; Mirja Kuehlewind <[email-masked]>; [email-masked]
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

The range probably comes from the IANA definition of the ephemeral ports (49152 to 65535) although these are defined for short-lived TCP and not explicitly for UDP. Why this made it into the yang model for TWAMP-test (which is UDP) I dont know, probably someone mixed it up with TCP and it passed the reviewers without much thought.
[acm]
https://tools.ietf.org/html/rfc6335#section-6
seems clear to me, without making the distinction between TCP and UDP
you mention. There was discussion on the ippm-list IIRC, too.

Most, if not all, implementations of TWAMP I have seen does not impose limitations on the source UDP ports for the TWAMP-test packets when configuring via CLI. For example neither Accedian, Exfo, Viavi, Juniper, Nokia, Huawei impose any limitation like that when configuring via CLI or GUI.

With a yang model based configuration the user will of course be limited if they use the yang model that only defines the ephemeral range as valid. I see no severe disadvantages of this, but it would of course have been better if the yang model was less restrictive, since the restriction has no real value in itself.

[acm] ...except avoiding a port assigned by IANA...

Al

On Tue, Aug 6, 2019 at 8:07 PM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Henrik. Where does this requirement come from? Also, how do I configure the UDP port outside the range using the TWAMP Yang model?

Thanks,
Rakesh

On Tue, Aug 6, 2019 at 11:19 AM Henrik Nydell <[email-masked]<mailto:[email-masked]>> wrote:
There is a distinction between "must be able to send to these destination ports" and "must only be able to send to these destination ports"

The first wording does not prohibit senders to be able to send also to other destination ports.

On Tue, Aug 6, 2019 at 4:57 PM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
Many thanks for the reply.
As there are already implementations out there where such restrictions do not exist as discussed in another email thread (just forwarded them), the following text with MUST is already violated. The TWAMP Yang model draft-ietf-ippm-twamp-yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dtwamp-2Dyang-2D13&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=HR_5ntwVu98MLVsNSbfLkeGlQc_DST02a_jurALHOPQ&e=> should also not place such restriction.
Section 4.4
       Thus STAMP Session-Sender MUST be able to send test
       packets to destination UDP port number from the Dynamic and/or
       Private Ports range 49152-65535, test management system should find a
       port number that both devices can use.

Thanks,
Rakesh

On Sat, Aug 3, 2019 at 1:05 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,
my apologies for the misspelling of your name.
Thank you for your kind consideration of the proposed update.
Regarding the definition of the range of the valid UDP port numbers, draft-ietf-ippm-twamp-yang<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dtwamp-2Dyang-2D13&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=HR_5ntwVu98MLVsNSbfLkeGlQc_DST02a_jurALHOPQ&e=> uses type dynamic-port-number as follows:
     typedef dynamic-port-number {
       type inet:port-number {
         range 49152..65535;
       }
       description "Dynamic range for port numbers.";
     }
to specify the valid range for a sender-udp-port. The range for a UDP port number of a Session-Reflector has been specified slightly differently because it includes the well-known port 862:
           leaf reflector-udp-port {
             type inet:port-number {
               range "862 | 49152..65535";
               }
             description
               "The destination UDP port number used in the
                TWAMP-Test (UDP) test packets belonging to this
                test session.";
           }
But, as we observe, in both cases definitions include the Dynamic/Private range explicitly defined. I think that keeping STAMP specification consistent with the TWAMP, TWAMP YANG data model in particular, in the way the valid range of UDP ports is being specified, is beneficial to the STAMP document. Hope you'll agree.

Regards,
Greg

On Fri, Aug 2, 2019 at 10:53 AM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Greg for considering my review comments.
Good to see the message format aligned with draft-ietf-ippm-stamp-option-tlv and using MBZ 30. This should fix the interoperability issue between the two. This also gives few (3) bytes for any future extensions.
------------------------------------------------------------------------
You may fix the spelling of my name and another typo below:
OLD:
and Rakesh Gandi or their

NEW:

I did not see following comment addressed. Is that intentional?
------------------------------------------------
On Tue, Jul 9, 2019 at 9:11 AM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:

    In this case, should the draft just state that the Session-Sender can select destination UDP port number following the guidelines specified in [RFC6335], instead of specifying following?

Section 4.4

Thanks,
Rakesh

On Fri, Aug 2, 2019 at 1:00 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,
thank you for your helpful comments. We've updated the format of the base STAMP test packet. Appreciate your feedback on the proposed changes, comments and questions,

Regards,
Greg

On Tue, Jul 9, 2019 at 9:27 AM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
Regarding the size of the padding, yes, it's good to use the same size payload for query and response.
However, the STAMP payload with TLV extension (draft-mirsky-ippm-stamp-option-tlv-01) has slightly different padding size (27 ( or > 29) vs. 30). Is there a way to make them compatible? Does it mean that for STAMP with TLV, Server Octets is set to 1, but it says MBZ 0 for all 30 bytes. If the responder supports Server Octets and see the size > 27, it may find the Server Octet size of 0 confusing?

Thanks,
Rakesh

On Mon, Jul 8, 2019 at 7:20 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Shahram,
thank you for the review and questions. Please find my answers below tagged GIM>>.

Regards,
Greg

On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <[email-masked]<mailto:[email-masked]>> wrote:
HI Greg

1) Does it require any UDP/TCP port number or it reuses the one from TWAMP? if it reuses from TWAMP then  how does the receiver differentiate between TWAMP and STAMP?
GIM>> STAMP uses the well-known UDP port number allocated for the OWAMP-Test/TWAMP-Test Receiver port (RFC 8545) as the default destination UDP port number.. STAMP may use destination UDP port number from the Dynamic and/or Private Ports range 49152-65535.
2) What is the benefit of STAMO compared to TWAMP?
GIM>> The work was driven by several observations, among them:

  *   challenges in achieving interoperability among implementations of TWAMP-Light;
  *   industry interest in standardizing performance monitoring in IP broadband access networks (TR-390);
  *   improve extensibility of IP performance monitoring tool to support measurements, testing of new metrics and parameters, e.g., consistency of CoS in the network.
3) Why is there so much MBZ byte?
GIM>> It was agreed to make the symmetrical size of STAMP test packets the default. RFC 6038 defined it for TWAMP and TR-390 requires it to be supported by TWAMP-Light implementations.

Thx
Shahram

On Jul 8, 2019, at 10:17 AM, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:

Hi Mirja,

If it is acceptable, I'd like to upload the updated version of draft-ieff-ippm-stamp before the cut-off deadline.

Regards,
Greg

On Mon, Jul 8, 2019 at 8:58 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

See below.

> On 8. Jul 2019, at 16:54, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi Mirja,
> thank you for the reference to RFC 8085. I agree that the document is very much relevant and a reference to RFC 8085 in STAMP is useful. While reading Section 3.1.3 I came to think that the discussion and guidance in other sections of RFC 8085, particularly, Section 3.1.5 Implications of RTT and Loss Measurements on Congestion Control. Would adding the reference to that section in the new text proposed for the Security Considerations section work? I'll put RFC 8085 as Informational reference as it is BCP.
> NEW TEXT:
>       particular before launching the test session....

Not sure if “using” is the right word but otherwise fine for me. Or you could have a separate sentence like:

“RFC8085 section 3.1.5 provides guidance on handling network load for UDP-based protocol. While the characteristic of test traffic depends on the test objective, it is highly recommended to say in the limits as provided in RFC8085.”

Or something similar…

BCP is the same maturity level as PS. So it wouldn’t be a downref. However, I think having this as informational ref is fine.

Mirja

>
> Regards,
> Greg
>
> On Mon, Jul 8, 2019 at 2:37 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Greg,
>
> Thanks a lot for you reply. Changes are good. I wonder if it would be useful to provide a reference to RFC8085 because it has a lot of information about congestion control of UDP based traffic? It recommends to send not more than 1 packet per 3 seconds (if RTT is unknown). I guess it doesn’t make sense to require this for testing traffic, however, it could maybe still be a good recommendation? What do you think?
>
> Also I’ve just resend my review to the IPPM list, as I unfortunately cc’ed only the IPPM chairs instead of the whole list. Can you resend you proposed changes to the list, so other people are aware of these changes. Sorry for the unconvience.
>
> Mirja
>
>
> > On 6. Jul 2019, at 17:46, Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hi Mirja,
> > thank you for your thorough review, very pointed and helpful comments. Please find my responses in-lined and tagged GIM>>. Attached the diff.
> >
> > Regards,
> > Greg
> >
> > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>> wrote:
> > Hi authors, hi all,
> >
> > Thanks for this well-written document and very good shepherd write-up! I would like discuss one point before I start IETF last call.
> >
> > I believe this document should say something about network load and congestion (control). OWAMP and TWAMP discuss quite a bit sender scheduling, however, as this is a simplified version, so I think it could at least be good to put a waring in this document that packet sending should be somehow rate limited. I know it might be hard to provide more concrete guidance but at least having some discussion or warning in this document could be good.
> > GIM>>  Thank you for your suggestion. Security Considerations section points to the fact that STAMP does not include control and management components:
> >    Because of the control
> > Another comment: You only say at the very end that a certain UDP port is used, which implies that STAMP runs over UDP. However, I think you should mention at the very beginning that this is a UDP-based protocol. Just to make things crystal clear.
> > GIM>> Adding the reference to "UDP transport" into the first sentence of Theory of  Operations section:
> >    STAMP Session-Sender transmits test packets over UDP transport toward STAMP Session-Reflector.
> >
> > Mirja
> >
> > P.S.:
> > Nit: s/This document defines active performance measurement test protocol/ This document defines an active performance measurement test protocol/
> > -> “an” missing
> > GIM>> Thank you. Done.
> > <Diff_ draft-ietf-ippm-stamp-06.txt - draft-ietf-ippm-stamp-07....txt.html>
>
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=E34uqKmQdO2Vs1uXtW7HIiPr4co6fApp7dRo_EPCiio&e=>

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=E34uqKmQdO2Vs1uXtW7HIiPr4co6fApp7dRo_EPCiio&e=>

--

Henrik Nydell
Sr Product Manager
1.866.685.8181
[email-masked]<mailto:[email-masked]>
[https://i.xink.io/Images/Get/N63832/a65.png]<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=w-fFLajYSxdAGnDPgc5eJL9Ke1Fxt_ZUh7g2JxMXFmw&e=> [https://i.xink.io/Images/Get/N63832/t99.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aLxX-L8YFiio4PJusnMzJACdZYIkFz5kzSYYg33tHXY&e=>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aV10PvZ65gihBtrcyRfWWFZ3Opvaf3e4gzQ9pRJIum0&e=>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=PowT9C9_E09Yg8toWCa4x0cfFsepQJ8D1Dhd9LZ1az4&e=>
accedian.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>

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.

--

Henrik Nydell
Sr Product Manager
1.866.685.8181
[email-masked]<mailto:[email-masked]>
[https://i.xink.io/Images/Get/N63832/a65.png]<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=w-fFLajYSxdAGnDPgc5eJL9Ke1Fxt_ZUh7g2JxMXFmw&e=> [https://i.xink.io/Images/Get/N63832/t99.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aLxX-L8YFiio4PJusnMzJACdZYIkFz5kzSYYg33tHXY&e=>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aV10PvZ65gihBtrcyRfWWFZ3Opvaf3e4gzQ9pRJIum0&e=>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=PowT9C9_E09Yg8toWCa4x0cfFsepQJ8D1Dhd9LZ1az4&e=>
accedian.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>

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: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Wed, 7 Aug 2019 14:28:49 +0000

Al

Thanks,
Rakesh

Thanks,
Rakesh

Regards,
Greg

NEW:

Section 4.4

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

---

From: Rakesh Gandhi <[email-masked]>
Date: Wed, 7 Aug 2019 12:01:54 -0400

Thanks Al and Henrik.
If there is no specific requirement to add a limit on the UDP port range,
it would be good to not have it in the STAMP draft as well as in the TWAMP
Yang model. Let implementations decide what ports they can support (keeping
in mind the assigned ones) and let operators decide what port they like to
provision.

Thanks,
Rakesh

On Wed, Aug 7, 2019 at 10:34 AM MORTON, ALFRED C (AL) <[email-masked]>
wrote:

>
>
> *From:* ippm [mailto:[email-masked]] *On Behalf Of *Henrik Nydell
> *Sent:* Wednesday, August 7, 2019 4:30 AM
> *To:* Rakesh Gandhi <[email-masked]>
> *Cc:* IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>;
> Mirja Kuehlewind <[email-masked]>; [email-masked]
> *Subject:* Re: [ippm] AD review of draft-ietf-ippm-stamp
>
>
>
> *[acm] *
> *[acm] ...*except avoiding a port assigned by IANA...
>
>
> Al
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dtwamp-2Dyang-2D13&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=HR_5ntwVu98MLVsNSbfLkeGlQc_DST02a_jurALHOPQ&e=>
> should also not place such restriction.
>
> Section 4.4
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dtwamp-2Dyang-2D13&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=HR_5ntwVu98MLVsNSbfLkeGlQc_DST02a_jurALHOPQ&e=> uses
> type dynamic-port-number as follows:
>
> On Mon, Jul 8, 2019 at 2:02 PM Shahram Davari <[email-masked]>
> wrote:
>
> HI Greg
>
>
>
> GIM>> It was agreed to make the symmetrical size of STAMP test packets the
> default. RFC 6038 defined it for TWAMP and TR-390 requires it to be
> > > On 6. Jul 2019, at 17:46, Greg Mirsky <[email-masked]> wrote:
> > >
> > > Hi Mirja,
> > > thank you for your thorough review, very pointed and helpful comments.
> Please find my responses in-lined and tagged GIM>>. Attached the diff.
> > >
> > > Regards,
> > > Greg
> > >
> > > On Thu, Jul 4, 2019 at 9:10 AM Mirja Kuehlewind <[email-masked]>
> wrote:
> > > Hi authors, hi all,
> > >
> > > Thanks for this well-written document and very good shepherd write-up!
> I would like discuss one point before I start IETF last call.
> > >
> > > GIM>>  Thank you for your suggestion. Security Considerations section
> points to the fact that STAMP does not include control and management
> components:
> > >    Because of the control
> > > Another comment: You only say at the very end that a certain UDP port
> is used, which implies that STAMP runs over UDP. However, I think you
> draft-ietf-ippm-stamp-07....txt.html>
> >
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=E34uqKmQdO2Vs1uXtW7HIiPr4co6fApp7dRo_EPCiio&e=>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=E34uqKmQdO2Vs1uXtW7HIiPr4co6fApp7dRo_EPCiio&e=>
>
>
>
>
> --
>
>
> *Henrik Nydell*
> *Sr Product Manager*
> 1.866.685.8181
> [email-masked]
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=w-fFLajYSxdAGnDPgc5eJL9Ke1Fxt_ZUh7g2JxMXFmw&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aLxX-L8YFiio4PJusnMzJACdZYIkFz5kzSYYg33tHXY&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aV10PvZ65gihBtrcyRfWWFZ3Opvaf3e4gzQ9pRJIum0&e=>
>
> *accedian.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>*
>
>
>
> Avis de confidentialité
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=w-fFLajYSxdAGnDPgc5eJL9Ke1Fxt_ZUh7g2JxMXFmw&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aLxX-L8YFiio4PJusnMzJACdZYIkFz5kzSYYg33tHXY&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=aV10PvZ65gihBtrcyRfWWFZ3Opvaf3e4gzQ9pRJIum0&e=>
>
> *accedian.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=1R8CllooSt2dqOo0-DH2rdXfJekuy3wxuSNLuWjIu-o&s=tAu0zypg68sbTH9kW4JrcYJbC1tOAMX_NwNfNh5QMqQ&e=>*
>
>
>
> Avis de confidentialité
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 7 Aug 2019 16:42:26 -0700

Hi Rakesh,
thank you for your kind consideration of my responses and very pointed
questions. Please find my follow-up notes in-line below under GIM>> tag.

Regards,
Greg

On Tue, Aug 6, 2019 at 11:15 AM Rakesh Gandhi <[email-masked]>
wrote:

>>    - RFC 7820 is Experimental and, as I understand, the proposed
>>    solution is not seen kindly by the security experts, and for a good reason.
>>    As you've correctly pointed out, STAMP in unauthenticated mode may easily
>>    - I appreciate your interest in RFC 7750 (as one of co-authors).
>>    We've decided to support this functionality in an extension to STAMP. Class
>>    of Service TLV fully supports the functionality defined in RFC 7750 and
>>    offers the ability to instruct the Session-Reflector which DSCP value it
>>    must use for the reflected STAMP packet. Thus CoS marking consistency is
>>    verified in forward and reverse directions.
>>
GIM>> Though it is not part of the base specification, the ability to test
the consistency of CoS mapping on a path between STAMP Session-Sender and
Session-Reflector is supported by using the Class of Service TLV. And since
it has been recently adopted by IPPM WG, I don't think that such a
statement will be helpful to an implementor of STAMP.

>       equal to the value of Server Octets field starting with the Server
GIM>> I'm sorry you've had an older working version of the draft. Attached
is the current version and the text has been removed. Could you let me know
if this change is acceptable?

---

From: Henrik Nydell <[email-masked]>
Date: Thu, 8 Aug 2019 09:51:18 +0200

Agree Rakesh.
There is value in being able to for example as close as possibly mimic for
example a VoIP flow on a network path, using typical UDP ports (5060 for
example), and a typical VoIP IPG (20ms) and proper payload length to make
the TWAMP flows be treated in the same way as the real RTP traffic by the
network elements (firewalls, NAT or other port-sensitive devices).

On Wed, Aug 7, 2019 at 6:02 PM Rakesh Gandhi <[email-masked]> wrote:

> On Wed, Aug 7, 2019 at 10:34 AM MORTON, ALFRED C (AL) <
> [email-masked]> wrote:
>
>>
>>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thu, 8 Aug 2019 09:01:45 +0000

Hi Rakesh and Henrik,

working from the VoIP testing example below, it seems as though
“ability to test on a specific port in the User range,
with prior agreement of users on the tested network”
should have been asked for-as a feature during
YANG model development?

the authors used the Dynamic Range to avoid *accidentally*
stepping on IANA-allocated User ports during auto-allocation:

             leaf sender-udp-port {
               type union {
                 type dynamic-port-number;
                 type enumeration {
                   enum autoallocate {
                     description
                       "Indicates that the Contol-Client will
                        auto-allocate the TWAMP-Test (UDP) port number
                        from the dynamic port range.";
                   }
with RFC 6335:
6.  Port Number Ranges

   TCP, UDP, UDP-Lite, SCTP, and DCCP use 16-bit namespaces for their
   port number registries.  The port registries for all of these
   transport protocols are subdivided into three ranges of numbers
   [RFC1340], and Section 8.1.2 describes the IANA procedures for each
   range in detail:

   o  the System Ports, also known as the Well Known Ports, from 0-1023
      (assigned by IANA)

   o  the User Ports, also known as the Registered Ports, from 1024-
      49151 (assigned by IANA)

providing our over-riding guidance.

If we agree that the sort of testing you describe means
adding a new feature to the model, then let’s give some thought
to how that might best be done.

Al

From: Henrik Nydell [mailto:[email-masked]]
Sent: Thursday, August 8, 2019 3:51 AM
To: Rakesh Gandhi <[email-masked]>
Cc: MORTON, ALFRED C (AL) <[email-masked]>; IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>; Mirja Kuehlewind <[email-masked]>; [email-masked]
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Agree Rakesh.
There is value in being able to for example as close as possibly mimic for example a VoIP flow on a network path, using typical UDP ports (5060 for example), and a typical VoIP IPG (20ms) and proper payload length to make the TWAMP flows be treated in the same way as the real RTP traffic by the network elements (firewalls, NAT or other port-sensitive devices).

On Wed, Aug 7, 2019 at 6:02 PM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:

Thanks Al and Henrik.
If there is no specific requirement to add a limit on the UDP port range, it would be good to not have it in the STAMP draft as well as in the TWAMP Yang model. Let implementations decide what ports they can support (keeping in mind the assigned ones) and let operators decide what port they like to provision.

Thanks,
Rakesh

On Wed, Aug 7, 2019 at 10:34 AM MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>> wrote:

From: ippm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Henrik Nydell
Sent: Wednesday, August 7, 2019 4:30 AM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: IPPM Chairs <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

The range probably comes from the IANA definition of the ephemeral ports (49152 to 65535) although these are defined for short-lived TCP and not explicitly for UDP. Why this made it into the yang model for TWAMP-test (which is UDP) I dont know, probably someone mixed it up with TCP and it passed the reviewers without much thought.
[acm]
https://tools.ietf.org/html/rfc6335#section-6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6335-23section-2D6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=Y3I4sW9cQ0UXh8cUXuPymXo9soP2KQFzein5oCkPdKE&e=>
seems clear to me, without making the distinction between TCP and UDP
you mention. There was discussion on the ippm-list IIRC, too.

Al

Thanks,
Rakesh

Thanks,
Rakesh

Regards,
Greg

NEW:

Section 4.4

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181
[email-masked]<mailto:[email-masked]>
[https://i.xink.io/Images/Get/N63832/a65.png]<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=UXlLLIWQPztVoCaATnyldPuiq5cMx4soEbPTGjmsJQE&e=>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=0ltpwFIjvuZ8sVhjuD2RN1tIgObw07RIgL_4j3vK9Zc&e=> [https://i.xink.io/Images/Get/N63832/t99.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=QTHdaq6bXMydVVJSnS8pfuhqEnLCWzO0tP9A-gyMWBA&e=>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=V_ehVarzjW8vvOqJeyq61146LyKQ_Rgz1fNJzJw1waI&e=>
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=9V6-ggZb009wP2eti0vCu9OWNz1EgxcbDPqe0xCailk&e=>
accedian.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=UXlLLIWQPztVoCaATnyldPuiq5cMx4soEbPTGjmsJQE&e=>

Avis de confidentialité

Confidentiality notice

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 8 Aug 2019 13:09:08 +0000

Thanks Henrik and Al for your feedbacks and discussions.

I have few comments on the TWAMP yang model draft-ietf-ippm-twamp-yang:

1)      Reflector side does not have autoallocate option. Only sender side has it and both allow dynamic range ports only (and 862).
      leaf reflector-udp-port {
               type inet:port-number {
                 range "862 | 49152..65535";
               }

     leaf sender-udp-port {
               type union {

2)      Autoallocate is still from the dynamic port range only.

3)      Even with the dynamic UDP port, the backend and controller still need to  handle the case where the UDP port has been allocated to something else on that node, as it is dynamic.

4)      Well known ports can be handled by the backend similarly if there was an error in provisioning.

5)      This range issue seems to get propagated to the new work like draft-ietf-ippm-stamp.

Other than the VOIP example below, there is another example of the similar case on Page 31 in https://www.ietf.org/id/draft-ietf-tram-turnbis-29.txt as pointed out by Mirja in another thread.

At this point, two vendors are saying the UDP port range for TWAMP is an issue for them. As the existing implementations do not have such range limit, operators may be using an UDP port outside this range, this means moving to the TWAMP Yang model could be troublesome.

Thanks,
Rakesh

From: ippm <[email-masked]> on behalf of "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Thursday, August 8, 2019 at 5:02 AM
To: Henrik Nydell <[email-masked]>, Rakesh Gandhi <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh and Henrik,

             leaf sender-udp-port {
               type union {

Al

Agree Rakesh.

Thanks Al and Henrik.

Thanks,
Rakesh

Al

Thanks,
Rakesh

Thanks,
Rakesh

Regards,
Greg

NEW:

Section 4.4

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 8 Aug 2019 13:24:44 +0000

Thank you Greg for the updates. They look good, I have couple of comments:

  1.  I did not see the updates for the first bullet (1) below regarding MBZ in the updated draft. Assuming it is pending.
  2.  It should still say something for the RFC 7750. Without any guidance, it can be implemented as specified in RFC 7750.

Thanks,
Rakesh

From: ippm <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Wednesday, August 7, 2019 at 7:43 PM
To: Rakesh Gandhi <[email-masked]>
Cc: IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh,
thank you for your kind consideration of my responses and very pointed questions. Please find my follow-up notes in-line below under GIM>> tag.

Regards,
Greg

On Tue, Aug 6, 2019 at 11:15 AM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
Thanks for your reply. Please see inline <RG>..

On Tue, Aug 6, 2019 at 12:14 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,
thank you for pointing to these two RFCs. Please consider my thoughts:

  *   (1) RFC 7820 is Experimental and, as I understand, the proposed solution is not seen kindly by the security experts, and for a good reason. As you've correctly pointed out, STAMP in unauthenticated mode may easily support the technique described in RFC 7820. But I'm not sure we have to do that in the base specification. What we can do is to relax language on MBZ and drop "MUST be zeroed on transmission" leaving "MUST be ignored on receipt". What do you think?
<RG> Ok with that.

  *   (2) I appreciate your interest in RFC 7750 (as one of co-authors). We've decided to support this functionality in an extension to STAMP. Class of Service TLV fully supports the functionality defined in RFC 7750 and offers the ability to instruct the Session-Reflector which DSCP value it must use for the reflected STAMP packet. Thus CoS marking consistency is verified in forward and reverse directions.
<RG> In that case, draft may say RFC7750 method is not supported by STAMP?
GIM>> Though it is not part of the base specification, the ability to test the consistency of CoS mapping on a path between STAMP Session-Sender and Session-Reflector is supported by using the Class of Service TLV. And since it has been recently adopted by IPPM WG, I don't think that such a statement will be helpful to an implementor of STAMP.
Also, I think the draft dropped supporting the server octet [RFC6038], right? If so, following text needs updating?
   o  (3) Packet Padding (reflected) is an optional variable length field..
      The length of the Packet Padding (reflected) field MUST be equal
      to the value of the Server Octets field (Figure 2).  If the value
      is non-zero, the Session-Reflector MUST copy number of octets
      equal to the value of Server Octets field starting with the Server
      Octets field.
GIM>> I'm sorry you've had an older working version of the draft. Attached is the current version and the text has been removed. Could you let me know if this change is acceptable?

Thanks,
Rakesh

Best regards,
Greg

On Tue, Aug 6, 2019 at 8:06 AM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
Couple of additional comments on the draft:
There are TWAMP extensions for Checksum complement in RFC 7820 and DSCP-ECN in RFC 7750. Good to add some text for STAMP if they can be supported or not supported. I can see they can be supported as following, and should not break anything:

0                   1                   2                   3

|                        Sequence Number                        |

|                        Transmit Timestamp                     |

|                                                               |

|         Error Estimate        |           MBZ                 |

|                      Receive Timestamp                        |

|                                                               |

|                      Sender Timestamp                         |

|                                                               |

Thanks,
Rakesh

On Mon, Jul 8, 2019 at 10:07 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh,
thank you for your question. In my experience, some implementations of TWAMP-Light have taken the liberty to allow using UDP port numbers outside the Dynamic/Private range. I believe that is not the right decision. In the note of IANA's Service Name and Transport Protocol Port Number Registry we read:

 [RFC8126]. User Ports are assigned by IANA using the "IETF Review" process,

My interpretation is that ports in System and User ranges, even if not yet assigned, must not be used without following the assignment process. Thus, regardless of whether a number had not yet been assigned to a service, it must not be used as the destination UDP port number. Also, consider operational issues if a new service is assigned a new port number from the User Ports range. One day the number was "free" and tomorrow it may be assigned. Handling such a scenario will add complexity while benefits are, in my opinion, questionable.

Regards,
Greg

On Mon, Jul 8, 2019 at 5:09 PM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Why limit the UDP port range to 49152-65535? Any free UDP port can be used, no?

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 8 Aug 2019 08:56:28 -0700

Hi Rakesh and Henrik,
thank you for a very informative discussion. Do you think the wording in
Section 4.4 of the STAMP specification needs modification:
   Thus STAMP Session-Sender MUST be able to send test
   packets to destination UDP port number from the Dynamic and/or
   Private Ports range 49152-65535, test management system should find a
   port number that both devices can use.
...
   In the latter scenario, the test management system SHOULD set STAMP
   Session-Reflector to use UDP port number from the Dynamic and/or
   Private Ports range.
I think that the text is not restrictive and can stay. What do you think?
We can review and update STAMP YANG model in a separate thread.

Regards,
Greg

On Thu, Aug 8, 2019 at 6:09 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> 1)      Reflector side does not have autoallocate option. Only sender
> side has it and both allow dynamic range ports only (and 862).
>
> 3)      Even with the dynamic UDP port, the backend and controller still
> need to  handle the case where the UDP port has been allocated to something
> else on that node, as it is dynamic.
>
> Other than the VOIP example below, there is another example of the similar
> case on Page 31 in https://www.ietf.org/id/draft-ietf-tram-turnbis-29.txt
> as pointed out by Mirja in another thread.
>
>
>
> At this point, two vendors are saying the UDP port range for TWAMP is an
> issue for them. As the existing implementations do not have such range
> limit, operators may be using an UDP port outside this range, this means
> moving to the TWAMP Yang model could be troublesome.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *From: *ippm <[email-masked]> on behalf of "MORTON, ALFRED C (AL)"
> <[email-masked]>
> *Date: *Thursday, August 8, 2019 at 5:02 AM
> *To: *Henrik Nydell <[email-masked]>, Rakesh Gandhi <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>,
> IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>,
> IETF IPPM WG <[email-masked]>
> *Subject: *Re: [ippm] AD review of draft-ietf-ippm-stamp
>
>
>
> Hi Rakesh and Henrik,
>
>
>
> *From:* Henrik Nydell [mailto:[email-masked]]
> *Sent:* Thursday, August 8, 2019 3:51 AM
> *Cc:* MORTON, ALFRED C (AL) <[email-masked]>; IPPM Chairs <
> [email-masked]>; IETF IPPM WG <[email-masked]>; Mirja Kuehlewind <
> [email-masked]>; [email-masked]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc6335-23section-2D6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=Y3I4sW9cQ0UXh8cUXuPymXo9soP2KQFzein5oCkPdKE&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=UXlLLIWQPztVoCaATnyldPuiq5cMx4soEbPTGjmsJQE&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_accedian_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=0ltpwFIjvuZ8sVhjuD2RN1tIgObw07RIgL_4j3vK9Zc&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Accedian&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=QTHdaq6bXMydVVJSnS8pfuhqEnLCWzO0tP9A-gyMWBA&e=>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_company_accedian-2Dnetworks-3ForiginalSubdomain-3Dca&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=V_ehVarzjW8vvOqJeyq61146LyKQ_Rgz1fNJzJw1waI&e=>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__accedian.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=r9g1UEMgj8gERHFnIHAPcl_wNNiTuU1MuEAyOEHtg0M&s=UXlLLIWQPztVoCaATnyldPuiq5cMx4soEbPTGjmsJQE&e=>*
>
>
>
> Avis de confidentialité
>

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 8 Aug 2019 12:31:13 -0700

Hi Rakesh,
many thanks for your comments.

   - I've updated MBZ to "MAY be zeroed on transmit and MUST be ignored on
   receipt".
   - I think that the fact RFC 7750 is not mentioned in this document
   should be interpreted as "not supported". If you believe that something
   should be said explicitly, would the following be acceptable

[RFC7750] is supported by optional extension specified in
[I-D.ietf-ippm-stamp-option-tlv].

Attached are, as usual, diff and the updated working version.

Much appreciate your help and commitment to making STAMP useful and
practical.

Regards,
Greg

On Thu, Aug 8, 2019 at 6:24 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

>    1. I did not see the updates for the first bullet (1) below regarding
>    MBZ in the updated draft. Assuming it is pending.
>    2. It should still say something for the RFC 7750. Without any
>    guidance, it can be implemented as specified in RFC 7750.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *From: *ippm <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Wednesday, August 7, 2019 at 7:43 PM
> *To: *Rakesh Gandhi <[email-masked]>
> *Cc: *IPPM Chairs <[email-masked]>, Mirja Kuehlewind <
> [email-masked]>, IETF IPPM WG <[email-masked]>, "
> [email-masked]" <[email-masked]>
>    - (1) RFC 7820 is Experimental and, as I understand, the proposed
>    - (2) I appreciate your interest in RFC 7750 (as one of co-authors).
> *0                   1                   2                   3*
> *0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1*
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *|                        Sequence Number                        |*
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *|                        Transmit Timestamp                     |*
>
> *|                                                               | *
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *|         Error Estimate        |           MBZ                 |*
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *|                      Receive Timestamp                        |*
>
> *|                                                               |*
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *|                      Sender Sequence Number                   |*
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *|                      Sender Timestamp                         |*
>
> *|                                                               |*
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *|      Sender Error Estimate    |           MBZ                 |*
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
> *|  Sender TTL   | S-DSCP-ECN    | Checksum Complement           |*
>
> *+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+*
>
>
>
> Thanks,
>
> Rakesh
>
>
>

---

From: Henrik Nydell <[email-masked]>
Date: Fri, 9 Aug 2019 11:51:14 +0200

Hi Greg, to make the wording even clearer you could change to

"Thus STAMP Session-Sender MUST as a minimum be able to send test
   packets to destination UDP port number from the Dynamic and/or
   Private Ports range 49152-65535 as well as the registered TWAMP port
862. Implementations MAY allow using ports outside the IANA assigned
Private Ports range."

On Thu, Aug 8, 2019 at 5:56 PM Greg Mirsky <[email-masked]> wrote:

>> Other than the VOIP example below, there is another example of the
>> similar case on Page 31 in
>> https://www.ietf.org/id/draft-ietf-tram-turnbis-29.txt as pointed out by
>> Mirja in another thread.
>>
>>
>>
>> *From: *ippm <[email-masked]> on behalf of "MORTON, ALFRED C
>> (AL)" <[email-masked]>
>> There is value in being able to for example as close as possibly mimic
>> for example a VoIP flow on a network path, using typical UDP ports (5060
>> for example), and a typical VoIP IPG (20ms) and proper payload length to
>> make the TWAMP flows be treated in the same way as the real RTP traffic by
>> the network elements (firewalls, NAT or other port-sensitive devices).
>>
>>
>>
>>
>>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Aug 2019 11:51:32 +0000

Thanks Henrik and Greg for the text proposals.

May be we can change the text as follows to allow the flexibility.

"Thus STAMP Session-Sender SHOULD be able to send test packets to destination UDP port number from the Dynamic and/or Private Ports range 49152-65535 as well as the registered TWAMP port 862. Implementations MAY allow using UDP port number outside the Private Ports range when the test management system finds a port number that both devices can use."

Thanks,
Rakesh

From: Henrik Nydell <[email-masked]>
Date: Friday, August 9, 2019 at 5:51 AM
To: Greg Mirsky <[email-masked]>
Cc: "=SMTP:rgandhi@cisco. com" <[email-masked]>, "MORTON, ALFRED C (AL)" <[email-masked]>, Rakesh Gandhi <[email-masked]>, "[email-masked]" <[email-masked]>, IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

"Thus STAMP Session-Sender MUST as a minimum be able to send test
   packets to destination UDP port number from the Dynamic and/or
   Private Ports range 49152-65535 as well as the registered TWAMP port 862. Implementations MAY allow using ports outside the IANA assigned Private Ports range."

On Thu, Aug 8, 2019 at 5:56 PM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Hi Rakesh and Henrik,
thank you for a very informative discussion. Do you think the wording in Section 4.4 of the STAMP specification needs modification:

Regards,
Greg

On Thu, Aug 8, 2019 at 6:09 AM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Henrik and Al for your feedbacks and discussions.

     leaf sender-udp-port {
               type union {

Thanks,
Rakesh

From: ippm <[email-masked]<mailto:[email-masked]>> on behalf of "MORTON, ALFRED C (AL)" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 8, 2019 at 5:02 AM
To: Henrik Nydell <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IPPM Chairs <[email-masked]<mailto:[email-masked]>>, Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh and Henrik,

             leaf sender-udp-port {
               type union {

Al

From: Henrik Nydell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 8, 2019 3:51 AM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: MORTON, ALFRED C (AL) <[email-masked]<mailto:[email-masked]>>; IPPM Chairs <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Agree Rakesh.

Thanks Al and Henrik.

Thanks,
Rakesh

Al

Thanks,
Rakesh

Thanks,
Rakesh

Regards,
Greg

NEW:

Section 4.4

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181
[email-masked]<mailto:[email-masked]>
[https://i.xink.io/Images/Get/N63832/a65.png]<http://accedian.com/>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://www.facebook.com/accedian/> [https://i.xink.io/Images/Get/N63832/t99.png] <https://twitter.com/Accedian>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://www.linkedin.com/company/accedian-networks?originalSubdomain=ca>
<http://www.accedian.com/>
accedian.com<http://accedian.com>

Avis de confidentialité

Confidentiality notice

---

From: Henrik Nydell <[email-masked]>
Date: Fri, 9 Aug 2019 13:52:20 +0200

Sounds good to me.

On Fri, Aug 9, 2019 at 1:51 PM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> "Thus STAMP Session-Sender SHOULD be able to send test packets to
> destination UDP port number from the Dynamic and/or Private Ports range
> 49152-65535 as well as the registered TWAMP port 862. Implementations MAY
> allow using UDP port number outside the Private Ports range when the test
> management system finds a port number that both devices can use."
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *From: *Henrik Nydell <[email-masked]>
> *Date: *Friday, August 9, 2019 at 5:51 AM
> *To: *Greg Mirsky <[email-masked]>
> *Cc: *"=SMTP:rgandhi@cisco. com" <[email-masked]>, "MORTON, ALFRED C
> (AL)" <[email-masked]>, Rakesh Gandhi <[email-masked]>, "
> [email-masked]" <[email-masked]>, IPPM
> Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>,
> <http://accedian.com/>
> <https://www.facebook.com/accedian/> [image:
> https://i.xink.io/Images/Get/N63832/t99.png]
> <https://twitter.com/Accedian> [image:
> https://i.xink.io/Images/Get/N63832/l54.png]

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Aug 2019 12:04:31 +0000

Hi Greg,
Thanks for considering my comments. Please see replies inline with <RG>..

From: Greg Mirsky <[email-masked]>
Date: Thursday, August 8, 2019 at 3:40 PM
To: "=SMTP:rgandhi@cisco. com" <[email-masked]>
Cc: Rakesh Gandhi <[email-masked]>, IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh,

  *   I've updated MBZ to "MAY be zeroed on transmit and MUST be ignored on receipt".
<RG> Thanks.

  *   I think that the fact RFC 7750 is not mentioned in this document should be interpreted as "not supported". If you believe that something should be said explicitly, would the following be acceptable
“[RFC7750] is supported by optional extension specified in [I-D.ietf-ippm-stamp-option-tlv].”
<RG> Yes, thanks.
<RG> BTW, I see following two texts for the timestamp format in Section 4.4. Is there a reason why the Reflector only supports NTP and it is MUST whereas Sender has the flexibility with NTP and PTP with SHOULD?
"The Session-Sender SHOULD use the default format for its timestamps - NTP. And it MAY use PTPv2 timestamp format.
<snip>
“The Session-Reflector MUST be set to use the default format for its timestamps, NTP.”
Thanks,
Rakesh

Much appreciate your help and commitment to making STAMP useful and practical.

Regards,
Greg

On Thu, Aug 8, 2019 at 6:24 AM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Greg for the updates. They look good, I have couple of comments:

Thanks,
Rakesh

From: ippm <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 7, 2019 at 7:43 PM
To: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Cc: IPPM Chairs <[email-masked]<mailto:[email-masked]>>, Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh,

Regards,
Greg

Thanks,
Rakesh

Best regards,
Greg

0                   1                   2                   3

|                        Sequence Number                        |

|                        Transmit Timestamp                     |

|                                                               |

|         Error Estimate        |           MBZ                 |

|                      Receive Timestamp                        |

|                                                               |

|                      Sender Timestamp                         |

|                                                               |

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Aug 2019 12:05:05 +0000

Thanks Henrik.

From: Henrik Nydell <[email-masked]>
Date: Friday, August 9, 2019 at 7:52 AM
To: "=SMTP:rgandhi@cisco. com" <[email-masked]>
Cc: Greg Mirsky <[email-masked]>, "MORTON, ALFRED C (AL)" <[email-masked]>, Rakesh Gandhi <[email-masked]>, "[email-masked]" <[email-masked]>, IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Sounds good to me.

On Fri, Aug 9, 2019 at 1:51 PM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Henrik and Greg for the text proposals.

Thanks,
Rakesh

From: Henrik Nydell <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 9, 2019 at 5:51 AM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Cc: "=SMTP:rgandhi@cisco. com" <[email-masked]<mailto:[email-masked]>>, "MORTON, ALFRED C (AL)" <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IPPM Chairs <[email-masked]<mailto:[email-masked]>>, Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Regards,
Greg

     leaf sender-udp-port {
               type union {

Thanks,
Rakesh

Hi Rakesh and Henrik,

             leaf sender-udp-port {
               type union {

Al

Agree Rakesh.

Thanks Al and Henrik.

Thanks,
Rakesh

Al

Thanks,
Rakesh

Thanks,
Rakesh

Regards,
Greg

NEW:

Section 4.4

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 9 Aug 2019 08:35:58 -0700

Hi Rakesh and Henrik,
much appreciate your ideas. I agree with the new text that includes "MAY"
as expressed by Rakesh. I think that Henrik's proposal to maintain "MUST"
for the Dynamic range is accurate and will ensure interoperability,
including with the existing implementations of TWAMP Light.
What do you think?

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 9 Aug 2019 09:14:18 -0700

Hi Rakesh, Henrik, et al.,
I've updated the working version of the draft. Attached, please find the
diff and the current copy of the document. Please let me know if I've
captured all the changes we've discussed.
On the question Rakesh has asked. These recommendations are part of Section
4.4 that details aspects of STAMP interoperability with TWAMP Light
implementations. All the normative language used in that section is not
applicable to the scenario when both systems support STAMP protocol.

Regards,
Greg

On Fri, Aug 9, 2019 at 5:05 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> *From: *Greg Mirsky <[email-masked]>
> *Date: *Thursday, August 8, 2019 at 3:40 PM
> *To: *"=SMTP:rgandhi@cisco. com" <[email-masked]>
> *Cc: *Rakesh Gandhi <[email-masked]>, IPPM Chairs <
> [email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM
> WG <[email-masked]>, "[email-masked]" <
> [email-masked]>
>    - I've updated MBZ to "MAY be zeroed on transmit and MUST be ignored
>    on receipt".
>
> <RG> Thanks.
>
> <RG> BTW, I see following two texts for the timestamp format in Section
> 4.4. Is there a reason why the Reflector only supports NTP and it is MUST
> whereas Sender has the flexibility with NTP and PTP with SHOULD?
>
> "The Session-Sender SHOULD use the default format for its timestamps -
> NTP. And it MAY use PTPv2 timestamp format.
>
> <snip>
>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Aug 2019 17:03:25 +0000

Hi Greg,
Thanks for your comments. As there is an alternate “MAY” option, IMO, having “MUST” creates unnecessary restriction, as some implementation may choose to only support that range because of “MUST”.

Thanks,
Rakesh

From: Greg Mirsky <[email-masked]>
Date: Friday, August 9, 2019 at 11:36 AM
To: "=SMTP:rgandhi@cisco. com" <[email-masked]>
Cc: Henrik Nydell <[email-masked]>, "MORTON, ALFRED C (AL)" <[email-masked]>, Rakesh Gandhi <[email-masked]>, "[email-masked]" <[email-masked]>, IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh and Henrik,
much appreciate your ideas. I agree with the new text that includes "MAY" as expressed by Rakesh. I think that Henrik's proposal to maintain "MUST" for the Dynamic range is accurate and will ensure interoperability, including with the existing implementations of TWAMP Light.
What do you think?

Regards,
Greg

On Fri, Aug 9, 2019 at 4:51 AM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Henrik and Greg for the text proposals.

Thanks,
Rakesh

Regards,
Greg

     leaf sender-udp-port {
               type union {

Thanks,
Rakesh

Hi Rakesh and Henrik,

             leaf sender-udp-port {
               type union {

Al

Agree Rakesh.

Thanks Al and Henrik.

Thanks,
Rakesh

Al

Thanks,
Rakesh

Thanks,
Rakesh

Regards,
Greg

NEW:

Section 4.4

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 9 Aug 2019 13:02:43 -0700

Hi Rakesh,
thank you for sharing your concern with the use of the normative language
that defines values of UDP port numbers that can be used by STAMP
Session-Sender and Session-Reflector. I hope you'll agree that the ability
to perform STAMP testing using port numbers only from the Dynamic range is
mandatory. The use of "MAY" in regard to UDP port numbers outside the
dynamic range is intended to stress that before initiating the test an
operator must thoroughly analyze, understand the possible impact on the
network, devices, and services that are present in the network. And thus
the specification allows, under certain conditions, the use of port numbers
from outside the dynamic range. I think that more details on the use of UDP
port numbers are appropriate in STAMP YANG data model document.
What do you think?

Regards,
Greg

On Fri, Aug 9, 2019 at 10:03 AM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> Hi Greg,
>
> Thanks for your comments. As there is an alternate “MAY” option, IMO,
> having “MUST” creates unnecessary restriction, as some implementation may
> choose to only support that range because of “MUST”.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> *Date: *Friday, August 9, 2019 at 11:36 AM
> *Cc: *Henrik Nydell <[email-masked]>, "MORTON, ALFRED C (AL)" <
> [email-masked]>, Rakesh Gandhi <[email-masked]>, "

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Aug 2019 20:41:21 +0000

Hi Greg,
STAMP Yang model SHOULD just follow the procedure defined in STAMP😊

Here is a similar example that uses “SHOULD” for such case.
https://www.ietf.org/id/draft-ietf-tram-turnbis-29.txt
Page 31:
In all cases, the server SHOULD only allocate ports from the range
   49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]),
   unless the TURN server application knows, through some means not
   specified here, that other applications running on the same host as
   the TURN server application will not be impacted by allocating ports
   outside this range.

Thanks,
Rakesh

Date: Friday, August 9, 2019 at 4:03 PM

Hi Rakesh,
thank you for sharing your concern with the use of the normative language that defines values of UDP port numbers that can be used by STAMP Session-Sender and Session-Reflector. I hope you'll agree that the ability to perform STAMP testing using port numbers only from the Dynamic range is mandatory. The use of "MAY" in regard to UDP port numbers outside the dynamic range is intended to stress that before initiating the test an operator must thoroughly analyze, understand the possible impact on the network, devices, and services that are present in the network. And thus the specification allows, under certain conditions, the use of port numbers from outside the dynamic range. I think that more details on the use of UDP port numbers are appropriate in STAMP YANG data model document.
What do you think?

Regards,
Greg

On Fri, Aug 9, 2019 at 10:03 AM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
Thanks for your comments. As there is an alternate “MAY” option, IMO, having “MUST” creates unnecessary restriction, as some implementation may choose to only support that range because of “MUST”.

Thanks,
Rakesh

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 9, 2019 at 11:36 AM
To: "=SMTP:rgandhi@cisco. com" <[email-masked]<mailto:[email-masked]>>
Cc: Henrik Nydell <[email-masked]<mailto:[email-masked]>>, "MORTON, ALFRED C (AL)" <[email-masked]<mailto:[email-masked]>>, Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, IPPM Chairs <[email-masked]<mailto:[email-masked]>>, Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh and Henrik,

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

     leaf sender-udp-port {
               type union {

Thanks,
Rakesh

Hi Rakesh and Henrik,

             leaf sender-udp-port {
               type union {

Al

Agree Rakesh.

Thanks Al and Henrik.

Thanks,
Rakesh

Al

Thanks,
Rakesh

Thanks,
Rakesh

Regards,
Greg

NEW:

Section 4.4

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Fri, 9 Aug 2019 20:55:19 +0000

Thanks Greg for the updates. Changes look good to me.
One outstanding issue with the Port range being discussed in another thread.
Thanks,
Rakesh

Date: Friday, August 9, 2019 at 12:26 PM

Hi Rakesh, Henrik, et al.,
I've updated the working version of the draft. Attached, please find the diff and the current copy of the document. Please let me know if I've captured all the changes we've discussed.
On the question Rakesh has asked. These recommendations are part of Section 4.4 that details aspects of STAMP interoperability with TWAMP Light implementations. All the normative language used in that section is not applicable to the scenario when both systems support STAMP protocol.

Regards,
Greg

On Fri, Aug 9, 2019 at 5:05 AM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
Thanks for considering my comments. Please see replies inline with <RG>..

Cc: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>, IPPM Chairs <[email-masked]<mailto:[email-masked]>>, Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>, IETF IPPM WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

Hi Rakesh,

Regards,
Greg

Thanks,
Rakesh

Hi Rakesh,

Regards,
Greg

Thanks,
Rakesh

Best regards,
Greg

0                   1                   2                   3

|                        Sequence Number                        |

|                        Transmit Timestamp                     |

|                                                               |

|         Error Estimate        |           MBZ                 |

|                      Receive Timestamp                        |

|                                                               |

|                      Sender Timestamp                         |

|                                                               |

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

---

From: Greg Mirsky <[email-masked]>
Date: Sat, 10 Aug 2019 15:14:13 -0700

Hi Rakesh,
please review the updated diff and the working version of the draft. Do you
think that the changes address your and Henrik's comments on the use of UDP
port numbers in STAMP? You'll notice that the use of the System ports is
not mentioned. I believe that this range of port numbers should not be
used. What do you think?
Much appreciate your comments, suggestions.

Regards,
Greg

On Fri, Aug 9, 2019 at 1:55 PM Rakesh Gandhi (rgandhi) <[email-masked]>
wrote:

> *Date: *Friday, August 9, 2019 at 12:26 PM
> On the question Rakesh has asked. These recommendations are part of
> Section 4.4 that details aspects of STAMP interoperability with TWAMP Light

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 11 Aug 2019 09:13:00 +0000

Agree with Greg, -2 on mentioning System Ports, other than 862.

Al

From: ippm [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Saturday, August 10, 2019 6:14 PM
To: Rakesh Gandhi (rgandhi) <[email-masked]>
Cc: [email-masked]; Mirja Kuehlewind <[email-masked]>; IPPM Chairs <[email-masked]>; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Rakesh,
please review the updated diff and the working version of the draft. Do you think that the changes address your and Henrik's comments on the use of UDP port numbers in STAMP? You'll notice that the use of the System ports is not mentioned. I believe that this range of port numbers should not be used. What do you think?
Much appreciate your comments, suggestions.

Regards,
Greg

On Fri, Aug 9, 2019 at 1:55 PM Rakesh Gandhi (rgandhi) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Greg for the updates. Changes look good to me..
One outstanding issue with the Port range being discussed in another thread.
Thanks,
Rakesh

Regards,
Greg

On Fri, Aug 9, 2019 at 5:05 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco..com<mailto:[email-masked]>> wrote:
Hi Greg,
Thanks for considering my comments. Please see replies inline with <RG>..

Hi Rakesh,

Regards,
Greg

On Thu, Aug 8, 2019 at 6:24 AM Rakesh Gandhi (rgandhi) <rgandhi@cisco..com<mailto:[email-masked]>> wrote:
Thank you Greg for the updates. They look good, I have couple of comments:

Thanks,
Rakesh

Hi Rakesh,

Regards,
Greg

On Tue, Aug 6, 2019 at 11:15 AM Rakesh Gandhi <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,
Thanks for your reply. Please see inline <RG>...

Thanks,
Rakesh

Best regards,
Greg

On Tue, Aug 6, 2019 at 8:06 AM Rakesh Gandhi <rgandhi.ietf@gmail..com<mailto:[email-masked]>> wrote:
Hi Greg,
Couple of additional comments on the draft:
There are TWAMP extensions for Checksum complement in RFC 7820 and DSCP-ECN in RFC 7750. Good to add some text for STAMP if they can be supported or not supported. I can see they can be supported as following, and should not break anything:

0                   1                   2                   3

|                        Sequence Number                        |

|                        Transmit Timestamp                     |

|                                                               |

|         Error Estimate        |           MBZ                 |

|                      Receive Timestamp                        |

|                                                               |

|                      Sender Timestamp                         |

|                                                               |

Thanks,
Rakesh

Regards,
Greg

On Mon, Jul 8, 2019 at 5:09 PM Rakesh Gandhi <rgandhi.ietf@gmail..com<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

>       particular before launching the test session.....

Or something similar…

Mirja

> > <Diff_ draft-ietf-ippm-stamp-06.txt - draft-ietf-ippm-stamp-07.....txt.html>
>
_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=jFjYqNADrDEqVvXPflbULUsKg7B5HwREGTlXhcStmto&s=bPh6MiQMjWWYualzxQVH4MX9nVqjPthfyTAtd1XOYbE&e=>

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ippm&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=jFjYqNADrDEqVvXPflbULUsKg7B5HwREGTlXhcStmto&s=bPh6MiQMjWWYualzxQVH4MX9nVqjPthfyTAtd1XOYbE&e=>

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Mon, 12 Aug 2019 12:36:51 +0000

Hi Greg,
The updated version addresses my comments. Many thanks for considering them and the discussions.

Thanks,
Rakesh

Date: Saturday, August 10, 2019 at 6:21 PM

Hi Rakesh,

Regards,
Greg

Regards,
Greg

Hi Rakesh,

Regards,
Greg

Thanks,
Rakesh

Hi Rakesh,

Regards,
Greg

Thanks,
Rakesh

Best regards,
Greg

0                   1                   2                   3

|                        Sequence Number                        |

|                        Transmit Timestamp                     |

|                                                               |

|         Error Estimate        |           MBZ                 |

|                      Receive Timestamp                        |

|                                                               |

|                      Sender Timestamp                         |

|                                                               |

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Tue, 13 Aug 2019 13:28:13 +0000

Thanks Rakesh and Henrik.

This does indeed look like an issue in the TWAMP YANG model. I don’t recall the reason why this was added, it’s likely as Henrik mentioned that this came from the ephemeral port range for TCP. I also went back to my 2017/2018 email threads with the co-authors and I couldn’t find any email discussions on this.

Process question: how do we handle this? TWAMP YANG<https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/> is in the editor queue in MISSREF state.

Regards,
Reshad.

From: Henrik Nydell <[email-masked]>
Date: Wednesday, August 7, 2019 at 4:30 AM
To: Rakesh Gandhi <[email-masked]>
Cc: Greg Mirsky <[email-masked]>, "Reshad Rahman (rrahman)" <[email-masked]>, Shahram Davari <[email-masked]>, "[email-masked]" <[email-masked]>, IPPM Chairs <[email-masked]>, Mirja Kuehlewind <[email-masked]>, IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] AD review of draft-ietf-ippm-stamp

Thanks,
Rakesh

As there are already implementations out there where such restrictions do not exist as discussed in another email thread (just forwarded them), the following text with MUST is already violated. The TWAMP Yang model draft-ietf-ippm-twamp-yang<https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> should also not place such restriction.

Thanks,
Rakesh

Regarding the definition of the range of the valid UDP port numbers, draft-ietf-ippm-twamp-yang<https://tools.ietf.org/html/draft-ietf-ippm-twamp-yang-13> uses type dynamic-port-number as follows:

Regards,
Greg

NEW:

Section 4.4

Thanks,
Rakesh

Regards,
Greg

Thanks,
Rakesh

Regards,
Greg

Thx
Shahram

Hi Mirja,

Regards,
Greg

See below.

Or something similar…

Mirja

> > <Diff_ draft-ietf-ippm-stamp-06.txt - draft-ietf-ippm-stamp-07...txt.html>
>

--

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

Avis de confidentialité

Confidentiality notice

--

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

Avis de confidentialité

Confidentiality notice

---

From: "Civil, Ruth" <[email-masked]>
Date: Thu, 15 Aug 2019 16:54:15 +0000

We did have a long discussion about allowing UDP ports outside of the dynamic range in the TWAMP Yang model (see the attached outlook thread).

I'm not sure of the repercussions of allowing TWAMP test traffic with UDP port numbers that are assigned to other protocols. 
For example,  if we started sending TWAMP test packets with a destination UDP port of 123 (NTP) to an IP address on a remote device.  How would an NTP application running on that device know that these are not NTP packets - and therefore that it should not intercept them and attempt to process them as such?

Cheers,
	Ruth

-----Original Message-----
From: Rakesh Gandhi <[email-masked]> 
Sent: Wednesday, August 07, 2019 8:56 AM
To: Henrik Nydell <[email-masked]>
Cc: Greg Mirsky <[email-masked]>; [email-masked]; Shahram Davari <[email-masked]>; [email-masked]; IPPM Chairs <[email-masked]>; Mirja Kuehlewind <[email-masked]>; IETF IPPM WG <[email-masked]>; [email-masked]
Subject: [**EXTERNAL**] Re: [ippm] AD review of draft-ietf-ippm-stamp

Thanks Henrik.
Adding the authors of the TWAMP Yang model to see if they have any thoughts on the UDP port range. It is still not an RFC, so may be this comment can be addressed if needed.
Thanks,
Rakesh

On Wed, Aug 7, 2019 at 4:30 AM Henrik Nydell <[email-masked]> wrote:

> (49152 to 65535) although these are defined for short-lived TCP and 
> not explicitly for UDP. Why this made it into the yang model for 
> TWAMP-test (which is UDP) I dont know, probably someone mixed it up 
> with TCP and it passed the reviewers without much thought.
>
> configuring via CLI. For example neither Accedian, Exfo, Viavi, 
> Juniper, Nokia, Huawei impose any limitation like that when 
> configuring via CLI or GUI.
>
> With a yang model based configuration the user will of course be 
> limited if they use the yang model that only defines the ephemeral range as valid

Subject: Re: Telco Minutes 2016-06-28
From: Mahesh Jethanandani <[email-masked]>
To: "Reshad Rahman (rrahman)" <[email-masked]>
Cc: "MORTON, ALFRED C (AL)" <[email-masked]>, Kostas Pentikousis <[email-masked]>, "Civil, Ruth" <[email-masked]>
Date: Wed, 29 Jun 2016 14:16:19 +0000

How about this?

The base model as we publish in the draft talks only about the dynamic range.

An example in appendix shows how one could deviate the model and add in the well-known ports.

Mahesh Jethanandani
[email-masked]

> On Jun 29, 2016, at 6:49 AM, Reshad Rahman (rrahman) <[email-masked]> wrote:
> 
> Apologies for not being clear, what I forgot to add is “I don’t know how
> to do that”.
> 
> 
> 
> 
>> On 2016-06-29, 9:19 AM, "MORTON, ALFRED C (AL)" <[email-masked]> wrote:
>> 
>> That works for me, thanks for the suggestion.
>> Al
>> 
>>> -----Original Message-----
>>> From: Reshad Rahman (rrahman) [mailto:[email-masked]]
>>> Sent: Wednesday, June 29, 2016 8:22 AM
>>> To: MORTON, ALFRED C (AL); Mahesh Jethanandani
>>> Cc: Kostas Pentikousis; Civil, Ruth
>>> Subject: Re: Telco Minutes 2016-06-28
>>> 
>>> I think what Mahesh is saying is that the question is how do we model a
>>> dynamic range in the standard model and allow for less restrictions in
>>> other implementations. Optional features usually relate to new
>>> leaf/container nodes. Here we¹d have a port which is 49152..65535 in the
>>> base model and we want to allow an ³augment² which would be less
>>> restrictive say 1Š 65535.
>>> 
>>> 
>>> 
>>> 
>>> On 2016-06-28, 10:37 PM, "MORTON, ALFRED C (AL)" <[email-masked]>
>>> wrote:
>>> 
>>>> I suppose the well-known and registered ranges are an if-feature,
>>>> as we discussed on the call for something else today.
>>>> 
>>>> The model has to have some way to deal with mandatory and optional
>>>> features, right?
>>>> 
>>>>> -----Original Message-----
>>>>> From: Mahesh Jethanandani [mailto:[email-masked]]
>>>>> Sent: Tuesday, June 28, 2016 10:30 PM
>>>>> To: MORTON, ALFRED C (AL)
>>>>> Cc: Kostas Pentikousis; Reshad Rahman; Civil, Ruth
>>>>> Subject: Re: Telco Minutes 2016-06-28
>>>>> 
>>>>> The question would still be how do we model it. We either remove the
>>>>> range and allow all ports or we force implementations to deviate.
>>>>> 
>>>>> Mahesh Jethanandani
>>>>> [email-masked]
>>>>> 
>>>>>> On Jun 28, 2016, at 7:25 PM, MORTON, ALFRED C (AL)
>>> <[email-masked]>
>>>>> wrote:
>>>>>> 
>>>>>> Hi Mahesh,
>>>>>> 
>>>>>> I think Brian's point was that we want to allow a wider
>>>>>> range of ports for specialized testing, and still guide
>>>>>> the user to normal == dynamic port range for typical tests.
>>>>>> So, Dynamic range is mandatory, other ranges are optional.
>>>>>> 
>>>>>> There would be no requirement to support the exhaustive
>>>>>> range of ports, but extra points for providing that support.
>>>>>> 
>>>>>> Al
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Mahesh Jethanandani [mailto:[email-masked]]
>>>>>>> Sent: Tuesday, June 28, 2016 8:03 PM
>>>>>>> To: MORTON, ALFRED C (AL)
>>>>>>> Cc: Kostas Pentikousis; Reshad Rahman; Civil, Ruth
>>>>>>> Subject: Re: Telco Minutes 2016-06-28
>>>>>>> 
>>>>>>> Al,
>>>>>>> 
>>>>>>> The current definition of the dynamic-port-numbers restricts the
>>> port
>>>>>>> numbers to the range 49152 .. 65535. The current set of sender-
>>> udp-
>>>>> port
>>>>>>> and reflector-udp-port use the definition of dynamic-port-range
>>>>>>> effectively restricting the ports to that range. If we have to
>>>>> support
>>>>>>> ³well known² ports, we would have to drop the type definition,
>>>>> allowing
>>>>>>> users to use any port. Is that a desirable behavior? Can we let
>>>>>>> individual implementations deviate if they want to provide that
>>>>> support?
>>>>>>> 
>>>>>>> I thought the standard restricted the port range to the dynamic
>>> port
>>>>>>> range...
>>>>>>> 
>>>>>>>>> On Jun 28, 2016, at 1:22 PM, MORTON, ALFRED C (AL)
>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hi TWAMP YANG-o-philes,
>>>>>>>> 
>>>>>>>> On:
>>>>>>>> AP2: Al to check A/V recording in order to see if something needs
>>> to
>>>>>>>> be done in -01 to address Brian's comment about "application
>>> level
>>>>>>>> changes". Due 1 July 2016
>>>>>>>> 
>>>>>>>> What Brian was asking about was TWAMP's ability to perform port-
>>>>>>> specific
>>>>>>>> tests, assuming the network IS reactive to the UDP port in use
>>> and
>>>>>>>> configuring the Reflector to receive traffic on a specific UDP
>>> port.
>>>>>>>> The example Brian gave was TWAMP testing to see if QUIC would
>>> work
>>>>>>>> on UDP port 80.  This is outside the dynamic range for typical
>>> TWAMP
>>>>>>>> use. See https://en.wikipedia.org/wiki/QUIC
>>>>>>>> 
>>>>>>>> If we want to support testing of well-known ports or registered
>>>>> ports
>>>>>>>> *as an option*, beyond the typical use, we would have to say so
>>> in
>>>>> the
>>>>>>>> paragraph below:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> sender-udp-port
>>>>>>>>         The UDP port number that is to be used by the Session-
>>>>> Sender
>>>>>>>>         for this TWAMP-Test session.  The number is restricted
>>> to
>>>>>>> the
>>>>>>>>         dynamic port range (49152 .. 65535).  A value of zero
>>>>>>>>         indicates that the Control-Client SHALL auto-allocate a
>>> UDP
>>>>>>>>         port number for this TWAMP-Test session.  The configured
>>>>> (or
>>>>>>>>         auto-allocated) value is advertized in the Sender Port
>>>>> field
>>>>>>>>         of the Request-TW-session message (see also Section 3.5
>>> of
>>>>>>>>         [RFC5357]).  Note that in the scenario where a device
>>> auto-
>>>>>>>>         allocates a UDP port number for a session, and the
>>> repeat
>>>>>>>>         parameter for that session indicates that it should be
>>>>>>>>         repeated, the device is free to auto-allocate a
>>> different
>>>>>>> UDP
>>>>>>>>         port number when it negotiates the next (repeated)
>>>>> iteration
>>>>>>>>         of this session.
>>>>>>>> 
>>>>>>>> Perhaps:
>>>>>>>> ... .           The number is normally restricted to the
>>>>>>>>         dynamic port range (49152 .. 65535). For specialized
>>>>> testing
>>>>>>>>         of well-known ports or registered ports, these port
>>> number
>>>>>>> ranges
>>>>>>>>         MUST also be made available.
>>>>>>>> 
>>>>>>>> see:
>>>>>>>> https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
>>>>>>>> 
>>>>>>>> Similar changes are required here (and in the Session Reflector
>>>>>>> section,
>>>>>>>> just search on "dynamic") :
>>>>>>>> 
>>>>>>>> reflector-udp-port
>>>>>>>>         This parameter defines the UDP port number that will be
>>>>> used
>>>>>>>>         by the Session-Reflector for this TWAMP-Test session.
>>> The
>>>>>>>>         number is restricted to the dynamic port range (49152 ..
>>>>>>>>         65535).  This value will be placed in the Receiver Port
>>>>>>> field
>>>>>>>>         of the Request-TW-Session message.  If this value is not
>>>>>>> set,
>>>>>>>>         the device SHALL use the same port number as defined in
>>> the
>>>>>>>>         server-tcp-port parameter of this twamp-session-
>>> request's
>>>>>>>>         parent twamp-client-ctrl-connection.
>>>>>>>> 
>>>>>>>> And we need to repeat these typedefs for well-known and
>>> registered:
>>>>>>>> 
>>>>>>>>  range "49152 .. 65535";
>>>>>>>> description "Dynamic range for port numbers";
>>>>>>>> 
>>>>>>>> And, these leafs need to reflect the choice of range:
>>>>>>>> 
>>>>>>>>        leaf sender-udp-port {
>>>>>>>>        description "Sender UDP port.";
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Kostas Pentikousis [mailto:[email-masked]]
>>>>>>>>> Sent: Tuesday, June 28, 2016 1:48 PM
>>>>>>>>> To: 'Mahesh Jethanandani'; MORTON, ALFRED C (AL); 'Reshad
>>> Rahman';
>>>>>>>>> 'Civil, Ruth'
>>>>>>>>> Subject: [draft-ietf-ippm-twamp-yang] Telco Minutes 2016-06-28
>>>>>>>>> 
>>>>>>>>> Hi All,
>>>>>>>>> 
>>>>>>>>> Please find below my rough notes and APs from the telco today.
>>>>> Please
>>>>>>>>> correct/amend as needed, I may have missed something.
>>>>>>>>> 
>>>>>>>>> 1. IETF 95 IPPM Proceedings comments:
>>>>>>>>> https://www.ietf.org/proceedings/95/minutes/minutes-95-ippm):
>>>>>>>>> Greg Mirsky - Document the port ranges.
>>>>>>>>> Brian T - What about Application level changes.
>>>>>>>>> Fred Baker asked about an IPv6 example in the document.
>>>>>>>>> Al Morton - Need to add there
>>>>>>>>> 
>>>>>>>>> We agreed to add an IPv6 example and check if anything is
>>> required
>>>>> to
>>>>>>>>> address Brian's comment.
>>>>>>>>> 
>>>>>>>>> 2. YANG Doctor's (Jan Lindblad <[email-masked]>) Review:
>>>>>>>>> 
>>>>>>>>> Based on the comments (and YANG's pov about formal
>>> specification),
>>>>> we
>>>>>>>>> discussed where should parameter descriptions appear and
>>> concluded
>>>>>>>>> that we should as a first step we will move the parameter
>>>>>>> descriptions
>>>>>>>>> from section 4 to section 5. Naming will also be simplified
>>> (first
>>>>>>>>> proposal attached). We will subsequently update the UML diagrams
>>>>> and
>>>>>>>>> adjust text accordingly.
>>>>>>>>> 
>>>>>>>>> Regarding the comment about scope/value given lack of
>>> operational
>>>>>>>>> commands and a way to collect results we agreed to move the 1st
>>>>> para
>>>>>>>>> from Appendix B into Scope. An Author's reply to Jan could point
>>> to
>>>>>>>>> LMAP etc. at this point.
>>>>>>>>> 
>>>>>>>>> We have no solution for the following comment: "Alternatively,
>>> it
>>>>>>>>> might be more convenient for operators if this was modeled as a
>>>>> small
>>>>>>>>> power of two value with the range 10..31." (context: leaf max-
>>> count
>>>>>>>>> range).
>>>>>>>>> 
>>>>>>>>> There's a bit of inconsistency about SHALL/MAY/SHOULD in the
>>> text
>>>>> and
>>>>>>>>> its representation in YANG. Example comment from Jan:
>>>>>>>>> 
>>>>>>>>>> Section 4.1 and section 4.2 describes the max-count leaf like
>>>>> this:
>>>>>>>>>> max-count
>>>>>>>>>>        If an attacking system sets the maximum value in Count
>>>>>>>>>>        (2**32), then the system under attack would stall for a
>>>>>>>>>>        significant period of time while it attempts to
>>> generate
>>>>>>>>>>        keys.  Therefore, TWAMP-compliant systems SHOULD have a
>>>>>>>>>>        configuration control to limit the maximum Count value.
>>>>>>>>> The
>>>>>>>>>>        default max-count value SHOULD be 32768.
>>>>>>>>>> 
>>>>>>>>>> Since the YANG module specifies a configurable max-count with a
>>>>>>>>> default of 32768, there is no longer any SHOULD about this, it's
>>>>> now
>>>>>>>>> MUST. Also the description seems to be cut out of its context
>>> and
>>>>>>>>> pasted here. There was no reference to attacking systems before
>>>>> this,
>>>>>>>>> so maybe a line of introduction would be in order.
>>>>>>>>>> 
>>>>>>>>>> Section 4.4 has similar wording
>>>>>>>>>>        The default value of
>>>>>>>>>>        REFWAIT SHALL be 900 seconds, and this waiting time MAY
>>> be
>>>>>>>>>>        configurable.
>>>>>>>>>> 
>>>>>>>>>> The YANG module specifies a leaf refwait that makes this
>>>>>>>>> configurable. There is no MAY about it. If we would want to keep
>>>>> the
>>>>>>>>> MAY in this statement, the leaf would have to be flagged with an
>>>>>>>>> if-feature.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> *Action Points*
>>>>>>>>> 
>>>>>>>>> AP1: Reshad to address Fred's comment and add IPv6 example. Due
>>> 4
>>>>>>> July
>>>>>>>>> 2016.
>>>>>>>>> 
>>>>>>>>> AP2: Al to check A/V recording in order to see if something
>>> needs
>>>>> to
>>>>>>>>> be done in -01 to address Brian's comment about "application
>>> level
>>>>>>>>> changes". Due 1
>>>>>>>>> July 2016
>>>>>>>>> 
>>>>>>>>> AP3: Kostas to move descriptions from section 4 into the YANG
>>>>> module
>>>>>>>>> (and then back into section 5), adjust section 4. Due 5 July
>>> 2016
>>>>>>>>> 
>>>>>>>>> AP4: Kostas to edit Scope and incorporate para from Appendix B
>>> re:
>>>>>>>>> results collection. Due 5 July 2016
>>>>>>>>> 
>>>>>>>>> AP5: Mahesh will get in touch with Jan for an elegant YANG
>>> solution
>>>>>>> to
>>>>>>>>> describe ranges as power of two. Due 5 July 2016.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> *Next Telco*
>>>>>>>>> 
>>>>>>>>> 7 July 2016, 5 pm CEST/11 am ET/8 am PT. Kostas will send a
>>>>> blocker,
>>>>>>>>> Mahesh/Reshad to arrange bridge.
>>>>>>>>> 
>>>>>>>>> Best regards,
>>>>>>>>> 
>>>>>>>>> Kostas
>>>>>>> 
>>>>>>> Mahesh Jethanandani
>>>>>>> [email-masked]
>

---

From: "Civil, Ruth" <[email-masked]>
Date: Mon, 19 Aug 2019 15:26:35 +0000

I have no objection to changing the range for the UDP port in the TWAMP yang model.  I guess we need concensus from the other authors, and I believe Kostas or Mahesh would need to update the document.

From: Rakesh Gandhi <[email-masked]>
Sent: Monday, August 19, 2019 11:13 AM
To: Civil, Ruth <[email-masked]>
Cc: Henrik Nydell <[email-masked]>; Greg Mirsky <[email-masked]>; [email-masked]; Shahram Davari <[email-masked]>; [email-masked]; IPPM Chairs <[email-masked]>; Mirja Kuehlewind <[email-masked]>; IETF IPPM WG <[email-masked]>; [email-masked]
Subject: Re: [**EXTERNAL**] Re: [ippm] AD review of draft-ietf-ippm-stamp

Hi Ruth,

Thanks for forwarding the email discussion.

There are several drafts [draft-ietf-ippm-stamp-07] [draft-ietf-tram-turnbis-29] those allow User port as well as dynamic port ranges as defined in [RFC6335]. System ports are not allowed.

      (assigned by IANA)

      49151 (assigned by IANA)

   o  the Dynamic Ports, also known as the Private or Ephemeral Ports,

      from 49152-65535 (never assigned)

TWAMP Yang model [draft-ietf-ippm-twamp-yang-13] can also support the range to allow user ports. An example caveat is specified in [draft-ietf-tram-turnbis-29] as "unless the TURN server application knows, through some means not

   specified here, that other applications running on the same host as the TURN server application will not be impacted by allocating ports outside this range. "

Thanks,

Rakesh

On Thu, Aug 15, 2019 at 12:54 PM Civil, Ruth <[email-masked]<mailto:[email-masked]>> wrote:
We did have a long discussion about allowing UDP ports outside of the dynamic range in the TWAMP Yang model (see the attached outlook thread).

Cheers,
        Ruth

-----Original Message-----
From: Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 07, 2019 8:56 AM
To: Henrik Nydell <[email-masked]<mailto:[email-masked]>>
Cc: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Shahram Davari <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; IPPM Chairs <[email-masked]<mailto:[email-masked]>>; Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [**EXTERNAL**] Re: [ippm] AD review of draft-ietf-ippm-stamp

Thanks Henrik.

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 19 Aug 2019 11:12:56 -0400

Hi Ruth,

There are several drafts [draft-ietf-ippm-stamp-07]
[draft-ietf-tram-turnbis-29] those allow User port as well as dynamic port
ranges as defined in [RFC6335]. System ports are not allowed.

TWAMP Yang model [draft-ietf-ippm-twamp-yang-13] can also support the
range to allow user ports. An example caveat is specified in
[draft-ietf-tram-turnbis-29] as "unless the TURN server application
knows, through some means not
   specified here, that other applications running on the same host as
the TURN server application will not be impacted by allocating ports
outside this range. "

Thanks,

Rakesh

On Thu, Aug 15, 2019 at 12:54 PM Civil, Ruth <[email-masked]> wrote:

> We did have a long discussion about allowing UDP ports outside of the
> dynamic range in the TWAMP Yang model (see the attached outlook thread).
>
> I'm not sure of the repercussions of allowing TWAMP test traffic with UDP
> port numbers that are assigned to other protocols.
> For example,  if we started sending TWAMP test packets with a destination
> UDP port of 123 (NTP) to an IP address on a remote device.  How would an
> NTP application running on that device know that these are not NTP packets
> - and therefore that it should not intercept them and attempt to process
> them as such?
>
> Cheers,
>         Ruth
>
>
> Cc: Greg Mirsky <[email-masked]>; [email-masked]; Shahram
> Davari <[email-masked]>; [email-masked];
> IPPM Chairs <[email-masked]>; Mirja Kuehlewind <[email-masked]>;
> IETF IPPM WG <[email-masked]>; [email-masked]
> Adding the authors of the TWAMP Yang model to see if they have any
> thoughts on the UDP port range. It is still not an RFC, so may be this
> comment can be addressed if needed.
> Thanks,
> Rakesh
>
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 19 Aug 2019 17:24:54 +0200

Hi Rakesh,

Just quickly a comment on this bit:

> On 19. Aug 2019, at 17:12, Rakesh Gandhi <[email-masked]> wrote:
> 
> TWAMP Yang model [draft-ietf-ippm-twamp-yang-13] can also support the range to allow user ports. An example caveat is specified in [draft-ietf-tram-turnbis-29] 
> as "unless the TURN server application knows, through some means not
I don’t think it is the same thing for turn and stamp/twamp. 

In turn you aim at actually opening a connection to a remote endpoint and need to make sure that that endpoint is talking the same protocol as you do. That remote endpoint might actually implement different services on different ports. 

TWAMP is used for testing, therefore it could make sense to set up a testing server that listens on exactly the same port as your application would usually do. Yes, when using twamp on such ports, you have to make sure that your twamp server does not implement another protocol on that port but often these server are decided for testing only and preconfigured in a respective way.

Mirja

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 19 Aug 2019 12:38:42 -0400

Hi Mirja,
Thanks for your comments, yes, such appropriate caveat can be added for the
user port range in the TWAMP Yang mode.

Thanks,
Rakesh

On Mon, Aug 19, 2019 at 11:25 AM Mirja Kuehlewind <[email-masked]>
wrote:

> [draft-ietf-tram-turnbis-29]
> In turn you aim at actually opening a connection to a remote endpoint and
> need to make sure that that endpoint is talking the same protocol as you
> do. That remote endpoint might actually implement different services on
> different ports.
>
> TWAMP is used for testing, therefore it could make sense to set up a
> testing server that listens on exactly the same port as your application
> would usually do. Yes, when using twamp on such ports, you have to make
> sure that your twamp server does not implement another protocol on that
> port but often these server are decided for testing only and preconfigured
> in a respective way.
>
> Mirja
>
>
>

---

From: Henrik Nydell <[email-masked]>
Date: Mon, 19 Aug 2019 19:55:40 +0200

I think the Yang model should not put too many restrictions in place for
the port used for the TWAMP-test packets, neither source nor destination
ports. Although some ports are indeed assigned to specific services, the
idea of a test function often is to be able to as closely as possible mimic
the patterns of a real service.

Limiting the port at the application (TWAMP/STAMP) level would not be the
solution to "securing" an internet service, each application needs to have
enough protection to not become disturbed by unknown packets. As an
example, neither Chrome nor Edge prevents me from entering URLs with
destination TCP ports that are reserved for other protocols. I moved my
private web server to port 88 (which is assigned to Kerberos, although I am
not using Kerberos) and both browsers were fine with letting me point to
SERVER:88

On Mon, Aug 19, 2019 at 6:38 PM Rakesh Gandhi <[email-masked]>
wrote:

> Hi Mirja,
> Thanks for your comments, yes, such appropriate caveat can be added for
> the user port range in the TWAMP Yang mode.
>
> Thanks,
> Rakesh
>
>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Rakesh Gandhi <[email-masked]>
Date: Tue, 20 Aug 2019 07:41:03 -0400

Hi Henrik,
Agree.

Thanks,
Rakesh

On Mon, Aug 19, 2019 at 1:55 PM Henrik Nydell <[email-masked]> wrote:

>>> In turn you aim at actually opening a connection to a remote endpoint
>>> and need to make sure that that endpoint is talking the same protocol as
>>> you do. That remote endpoint might actually implement different services on
>>> different ports.
>>>