Re: [ippm] WGLC for STAMP Extensions

Hi Rakesh,
many thanks for the suggested text. I understand the intention of the
change but I think that the text proposed earlier, that Al has agreed to,
does not mandate that a Session-Reflector was provisioned with a specific
for the particular STAMP test session value of SSID. Provisioning, in my
view, could be as simple as leaving it a wildcard, i.e. Any. If we can
agree with this interpretation in this document, we'll decide on the
default values for all elements in the STAMP YANG data model. I hope you
can accept that.

Regards,
Greg

On Thu, Jun 11, 2020 at 8:07 AM Rakesh Gandhi <rgandhi.ietf@gmail.com>
wrote:

> Hi Greg,
> Basically removing the need to provision the SSID on the reflector node.
> So new text may look like:
>
>    An implementation of STAMP Session-Reflector that supports this
>    specification SHOULD identify a STAMP Session using the SSID in
>    combination with elements of the usual 4-tuple for the session.
>
>
>    Before a test session commenced, a Session-Reflector MUST be
>    provisioned with elements of the usual 4-tuple for the Session.  A
>    STAMP Session-Reflector MUST discard the non-matching STAMP test
>    packet(s).  The means of provisioning the STAMP Session
>    identification is outside the scope of this specification.
>
>
>
>    A conforming implementation of STAMP Session-Reflector MUST copy the
>    SSID value from the received test packet and put it into the
>    reflected packet, as displayed in Figure 2.
>
>
>
> Thanks,
>
> Rakesh
>
>
>
>
>
> On Thu, Jun 11, 2020 at 10:44 AM Greg Mirsky <gregimirsky@gmail.com>
> wrote:
>
>> Hi Rakesh,
>> thank you for your quick response. Below is the text proposed in the
>> update:
>>    Before a test session commenced, a Session-Reflector MUST be
>>    provisioned with all the elements that identify the STAMP Session.  A
>>    STAMP Session-Reflector MUST discard the non-matching STAMP test
>>    packet(s).  The means of provisioning the STAMP Session
>>    identification is outside the scope of this specification.
>> The intention of the update is to point to the need to use the management
>> or control plane to provision a STAMP session on the Session-Reflector. At
>> the same time, the text does not specify which of the informational
>> elements be provisioned to the explicit values and which may use a
>> wildcard. If you have concerns with the update, could you please suggest
>> modifications or propose an alternative?
>>
>> Regards,
>> Greg
>>
>> On Thu, Jun 11, 2020 at 7:28 AM Rakesh Gandhi (rgandhi) <
>> rgandhi@cisco.com> wrote:
>>
>>> Hi Greg,
>>>
>>> The current (OLD) text in the document looks good to me.
>>>
>>> P.S. The goal for STAMP (with Simple) is to simplify such things when
>>> compared to TWAMP (RFC 5357).
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Rakesh
>>>
>>>
>>>
>>>
>>>
>>> *From: *ippm <ippm-bounces@ietf.org> on behalf of Greg Mirsky <
>>> gregimirsky@gmail.com>
>>> *Date: *Thursday, June 11, 2020 at 10:21 AM
>>> *To: *Rakesh Gandhi <rgandhi.ietf@gmail.com>
>>> *Cc: *"MORTON, ALFRED C (AL)" <acm@research.att.com>, Ian Swett
>>> <ianswett=40google.com@dmarc.ietf.org>, "IETF IPPM WG (ippm@ietf.org)" <
>>> ippm@ietf.org>
>>> *Subject: *Re: [ippm] WGLC for STAMP Extensions
>>>
>>>
>>>
>>> Hi Rakesh,
>>>
>>> I agree with your scenario. Do you feel that the document, including the
>>> updated text, precludes it? Would you suggest text clarifications?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Thu, Jun 11, 2020 at 7:13 AM Rakesh Gandhi <rgandhi.ietf@gmail.com>
>>> wrote:
>>>
>>> Thanks Greg.
>>>
>>> SSID can be internally generated by the sender node. Expecting sender
>>> node to communicate this to the controller and then to the reflector node
>>> for *each* session may be overkill.
>>>
>>>
>>>
>>> The destination UDP port to use on the reflector node is already
>>> provisioned value and not any arbitrary port can be used anyways. So that
>>> should help with such issues.
>>>
>>>
>>>
>>> My 2c.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Rakesh
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 10, 2020 at 9:32 PM Greg Mirsky <gregimirsky@gmail.com>
>>> wrote:
>>>
>>> Hi Rakesh,
>>>
>>> as Al clarified, and I agree with this scenario, a Session-Reflector
>>> must be provisioned with a session identifier (some elements, I think,
>>> might be specified as a wild card) before the session is commenced. All
>>> test packets that do not match the provisioned identifier must be discarded
>>> without processing. I've tried to capture that in the latest update sent
>>> earlier.
>>>
>>> What do you think of this scenario?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>> On Wed, Jun 10, 2020 at 4:36 PM Rakesh Gandhi <rgandhi.ietf@gmail.com>
>>> wrote:
>>>
>>> Hi Greg, Al,
>>>
>>> I am not sure if I follow the scenario.
>>>
>>> Between nodes A and B, there can be more than one STAMP sessions, e.g.
>>> {Node-A, Node-B, Src-Port-1, Dst-Port-1, SSID1} and {Node-A, Node-B,
>>> Src-Port-1, Dst-Port-1, SSID2}. I assume this is allowed? If yes, how do we
>>> know when there is now a third session between them with SSID3 (with same 4
>>> tuple), it is a change (from SSID1 or SSID2?) or a new third session?
>>>
>>> Thanks,
>>>
>>> Rakesh
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 10, 2020 at 7:21 PM Greg Mirsky <gregimirsky@gmail.com>
>>> wrote:
>>>
>>> Hi Al,
>>>
>>> many thanks for your quick response, much appreciated. We'll need some
>>> more time to discuss your suggestion related to the Access Report TLV. I've
>>> front-copied the other open issue and added my notes under the tag GIM2>>
>>> below.
>>>
>>>
>>>
>>>    An implementation of STAMP Session-Reflector that supports this
>>>
>>>    specification SHOULD identify a STAMP Session using the SSID in
>>>
>>>    combination with elements of the usual 4-tuple
>>>
>>> [acm] <insert> for the session. If the Session-Reflector finds that
>>>
>>> the SSID and 4-tuple combination changes during a test session, then
>>>
>>> the Session-Reflector MUST discard the non-matching packet(s) and take
>>>
>>> no further action on them.
>>>
>>>    .  A conforming...
>>>
>>> GIM>> We've discussed the scenario and couldn't define how a
>>> Session-Reflector can distinguish between a new STAMP test session and the
>>> event of a change in identifiers, i.e., SSID and 4-tuple of the ongoing
>>> test session. Could you kindly help us here?
>>>
>>>
>>>
>>> *[acm] Thanks, I’m surprised that a new test session (with new SSID) can
>>> begin without any Session-Reflector agreement or communication from the
>>> Session-Reflector’s management interface. Since the Sending address and
>>> port could be spoofed, Session-Reflectors could receive lots of unexpected
>>> traffic, if you know what I mean.....*
>>>
>>> GIM2>> Thank you for the clarification. I was not thinking out of a box.
>>> Please review the proposed new text below. I hope it captures the scenario
>>> you've pointed out.
>>>
>>> OLD TEXT:
>>>
>>>    An implementation of STAMP Session-Reflector that supports this
>>>    specification SHOULD identify a STAMP Session using the SSID in
>>>    combination with elements of the usual 4-tuple for the session.  A
>>>    conforming implementation of STAMP Session-Reflector MUST copy the
>>>    SSID value from the received test packet and put it into the
>>>    reflected packet, as displayed in Figure 2.
>>>
>>> NEW TEXT:
>>>
>>>    An implementation of STAMP Session-Reflector that supports this
>>>    specification SHOULD identify a STAMP Session using the SSID in
>>>    combination with elements of the usual 4-tuple for the session.
>>>    Before a test session commenced, a Session-Reflector MUST be
>>>    provisioned with all the elements that identify the STAMP Session.  A
>>>    STAMP Session-Reflector MUST discard the non-matching STAMP test
>>>    packet(s).  The means of provisioning the STAMP Session
>>>    identification is outside the scope of this specification.  A
>>>    conforming implementation of STAMP Session-Reflector MUST copy the
>>>    SSID value from the received test packet and put it into the
>>>    reflected packet, as displayed in Figure 2.
>>>
>>>
>>>
>>> Would the new text address your concern?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Greg
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 10, 2020 at 8:01 AM MORTON, ALFRED C (AL) <
>>> acm@research.att.com> wrote:
>>>
>>> Hi Greg, Thanks for all replies.
>>>
>>> Let’s concentrate on those needing some additional thought...
>>>
>>> Al
>>>
>>>
>>>
>>>
>>>
>>>    An implementation of STAMP Session-Reflector that supports this
>>>
>>>    specification SHOULD identify a STAMP Session using the SSID in
>>>
>>>    combination with elements of the usual 4-tuple
>>>
>>> [acm] <insert> for the session. If the Session-Reflector finds that
>>>
>>> the SSID and 4-tuple combination changes during a test session, then
>>>
>>> the Session-Reflector MUST discard the non-matching packet(s) and take
>>>
>>> no further action on them.
>>>
>>>    .  A conforming...
>>>
>>> GIM>> We've discussed the scenario and couldn't define how a
>>> Session-Reflector can distinguish between a new STAMP test session and the
>>> event of a change in identifiers, i.e., SSID and 4-tuple of the ongoing
>>> test session. Could you kindly help us here?
>>>
>>>
>>>
>>> *[acm] Thanks, I’m surprised that a new test session (with new SSID) can
>>> begin without any Session-Reflector agreement or communication from the
>>> Session-Reflector’s management interface. Since the Sending address and
>>> port could be spoofed, Session-Reflectors could receive lots of unexpected
>>> traffic, if you know what I mean..... *
>>>
>>>
>>>
>>>
>>>
>>> ...
>>>
>>>  …                 | 2     |   Non-3GPP  | This document |
>>>
>>>                   +-------+-------------+---------------+
>>>
>>> [acm] these seem overly broad, and unlikely to be extended because they
>>> *cover everything*!!
>>>
>>> GIM>> Here we've turned to our 3GPP expert... The current (Rel-16)
>>> specification of ATSSS defines only two access types - 3GPP and Non-3GPP.
>>> Creating a sub-registry and leaving a space for new types might help to
>>> accommodate potential changes in 5G specification and the development of
>>> new specifications, e.g., 6G, in the future.
>>>
>>> *[acm] *
>>>
>>> *Yes, but your examples of 5G and 6G would fall under the general
>>> category of “3GPP” (which I accidentally delated above).*
>>>
>>> *Maybe some additional detail would help, like “3GPP-LTE”, “3GPP-5G”,
>>> and make “Non-3GPP” the first entry so that expansion with new technologies
>>> starts at 2, 3, …*
>>>
>>>                             Table 8: Access IDs
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>>               +-------+---------------------+---------------+
>>>
>>>               | Value |     Description     | Reference     |
>>>
>>>               +-------+---------------------+---------------+
>>>
>>>               | 1     |  Network available  | This document |
>>>
>>>               | 2     | Network unavailable | This document |
>>>
>>>               +-------+---------------------+---------------+
>>>
>>> [acm] these seem overly broad, and imply knowledge where the STAMP
>>> end-point has limited insights!!
>>>
>>> GIM>>  These are defined in ATSSS specification of Performance
>>> Measurement Function. The value for the Return Code field is passed to
>>> STAMP system and it only transports it. Would a new text clarify the role
>>> of a STAMP system:
>>>
>>> OLD TEXT:
>>>
>>>    o  Return Code - one octet long field that identifies the report
>>>       signal, e.g., available, unavailable.  The value is one of those
>>>       listed in Section 5.5.
>>>
>>> NEW TEXT:
>>>
>>>    o  Return Code - one octet long field that identifies the report
>>>       signal, e.g., available, unavailable.  The value is passed,
>>>       supplied to the STAMP end-point through some mechanism that is
>>>       outside the scope of this document.  The value is one of those
>>>       listed in Section 5.5.
>>>
>>> *[acm] *
>>>
>>> *OK*
>>>
>>>                           Table 10: Return Codes
>>>
>>>
>>>
>>> ...
>>>
>>>
>>>
>>> 6.  Security Considerations
>>>
>>>
>>>
>>>    Use of HMAC in authenticated mode may be used to simultaneously
>>>
>>>    verify both the data integrity and the authentication of the STAMP
>>>
>>>    test packets.
>>>
>>> [acm] That's it? At least add reference to STAMP 8762 Security Section?
>>>
>>> GIM>> Thank you for your suggestion. The new text is below:
>>>
>>> NEW TEXT:
>>>
>>>    This document defines extensions to STAMP [RFC8762] and inherits all
>>>
>>>    the security considerations applicable to the base protocol.
>>>    Additionally, the HMAC TLV is defined in this document to protect the
>>>    integrity of optional STAMP extensions.  The use of HMAC TLV is
>>>    discussed in detail in Section 4.8.
>>>
>>>
>>>
>>> *[acm] OK*
>>>
>>> [acm] I suspect there will be some challenges for "Location" in future
>>>
>>>
>>>
>>>
>>>
>>> *From:* ippm [mailto:ippm-bounces@ietf.org] *On Behalf Of *Ian Swett
>>> *Sent:* Friday, May 22, 2020 5:26 PM
>>> *To:* IETF IPPM WG (ippm@ietf.org) <ippm@ietf.org>
>>> *Subject:* [ippm] WGLC for STAMP Extensions
>>>
>>>
>>>
>>> Hi IPPM,
>>>
>>> At our virtual interim meeting, we decided
>>> draft-ietf-ippm-stamp-option-tlv was ready for last call. This email starts
>>> a two-week WGLC for this draft.
>>>
>>> The latest version can be found here:
>>> https://tools.ietf.org/html/draft-ietf-ippm-stamp-option-tlv-04
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dippm-2Dstamp-2Doption-2Dtlv-2D04&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=-FQ_7VkardtUOemNdXjWGCdxDzw_8jcaV16Ots-GfRo&s=zadhVvE6IwVbJd0BcDUJdpX4xXqA4i60susVdbT5Pvg&e=>
>>>
>>> This last call will end on *Monday, June 8th*. Please reply to
>>> ippm@ietf.org with your reviews and comments.
>>>
>>> Thanks,
>>> Ian & Tommy
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.org
>>> 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=_6cen3Hn-e_hOm0BhY7aIpA58dd19Z9qGQsr8-6zYMI&m=AJPt25JReJLCcKTac6bW207kN8j0F2v7N7paNXkrS0Y&s=9RnqOZ8tzteJbGK2PJMpE2Y8RqKl-bvq-QfiStX4ywc&e=>
>>>
>>> _______________________________________________
>>> ippm mailing list
>>> ippm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ippm
>>>
>>>