Re: [ippm] [spring] Updates to draft-gandhi-spring-twamp-srpm-05.txt

[Rakesh Gandhi <[e-mail]>]

Thanks Greg for your review comments. Please see inline with <RG>..

On Mon, Mar 2, 2020 at 11:09 AM Greg Mirsky <[e-mail]> wrote:

> Dear Rakesh,
> my apologies for the belated response and comments that you can find below:
>
>    - as I understand, the draft is applicable to TWAMP Light mode,
>    mentioned in the informational Appendix I in RFC 5357, not the TWAMP
>    protocol itself. Since TWAMP Light is not a standard but its idea is
>    described in the informational text only, I think that the Informational
>    track is more appropriate for this specification.
>
> <RG> The document defines procedures for SR.


>
>    - I with the introduction of the Control Code field you propose the
>    update to the STAMP base test packet defined in draft-ietf-ippm-stamp
>    <https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/>. How the
>    proposed change benefits STAMP protocol? As I understand, the Control Code
>    field is introduced only for the benefit of the mechanism you propose for
>    the Segment Routing. Does it have broader applicability? Why not use the
>    accepted by IPPM WG STAMP extension model and use TLV?
>
> <RG> I will prepare few slides to discuss different options.


>
>    - also, the update introduces Loss Measurement Query Message Formats
>    and Loss Measurement Response Message Formats for STAMP, which are the
>    changes to draft-ietf-ippm-stamp, which has already been approved by IESG
>    for publication. I couldn't find the explanation of why these mechanisms
>    cannot use the extension mechanism already accepted by IPPM WG for STAMP,
>    TLVs, as has been done for Direct Loss Measurement. I hope the authors will
>    expand on the rationale of introducing new constructs in the STAMP base
>    specification instead of using the TLV-based extension mechanism.
>
> <RG> This was discussed previously.
https://mailarchive.ietf.org/arch/msg/ippm/JmS56RM5IskNSjshpFNGa9G_nf8/



> And in connection to my comments related to the proposed changes in STAMP
> is the question to SPRING and IPPM WGs Chairs:
>
>    - the authors of the draft have changed the title to reflect the
>    change in the scope of the draft.  Now the draft updates not only
>    informational document that was produced by IPMM WG but the standards track
>    document. I think that though Chairs of IPPM and SPRING WGs had discussed
>    where to anchor this specification, the change in scope may be significant
>    enough to require another round. Alternatively, changes to STAMP protocol
>    may be the basis for the new draft that, preferably, be anchored in the WG
>    that is actively working on defining the STAMP specification and the
>    mechanism to extend STAMP functionalities.
>
>
<RG> STAMP has been in the scope since the beginning.
Please see slide #9 presented in IPPM WG in Montreal at IETF 105 (July 2019)

https://datatracker.ietf.org/meeting/105/materials/slides-105-ippm-8-draft-gandhi-spring-twamp-srpm-01-00

Thanks,
Rakesh



> Regards,
> Greg
>
> On Fri, Jan 31, 2020 at 10:30 PM Rakesh Gandhi <[e-mail]>
> wrote:
>
>> Hi WG,
>> We have posted a revised draft with the following updates:
>>
>>    - Added control-code field (similar to RFC 6374)
>>    - Added Node-Address TLV (e.g. destination-address) – to carry the
>>    intended recipient of the probe query when using 127/8 address
>>    - Added Return Address in the Return Path TLV – to send reply to
>>    other than source-address
>>    - Added SR Policy with different endpoint addresses
>>    - Various editorial changes
>>
>>
>>
>> Welcome your review comments and suggestions.
>>
>> Thanks,
>>
>> Rakesh (on behalf of authors)
>>
>>
>> On 2019-12-05, 1:48 PM, "[e-mail]"
>> <[e-mail]> wrote:
>>
>>
>>
>>     A new version of I-D, draft-gandhi-spring-twamp-srpm-05.txt
>>
>>     has been successfully submitted by Rakesh Gandhi and posted to the
>>
>>     IETF repository.
>>
>>
>>
>>     Name:                              draft-gandhi-spring-twamp-srpm
>>
>>     Revision:          05
>>
>>     Title:                  Performance Measurement Using TWAMP Light
>> for Segment Routing Networks
>>
>>     Document date:           2019-12-05
>>
>>     Group:                              Individual Submission
>>
>>     Pages:                               30
>>
>>     URL:
>> https://www.ietf.org/internet-drafts/draft-gandhi-spring-twamp-srpm-05.txt
>>
>>     Status:
>> https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/
>>
>>     Htmlized:
>> https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-05
>>
>>     Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-gandhi-spring-twamp-srpm
>>
>>     Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-gandhi-spring-twamp-srpm-05
>>
>>
>>
>>     Abstract:
>>
>>        Segment Routing (SR) leverages the source routing paradigm.  SR is
>>
>>        applicable to both Multiprotocol Label Switching (SR-MPLS) and
>> IPv6
>>
>>        (SRv6) data planes.  This document specifies procedure for sending
>>
>>        and processing probe query and response messages for Performance
>>
>>        Measurement (PM) in Segment Routing networks.  The procedure uses
>> the
>>
>>        mechanisms defined in RFC 5357 (Two-Way Active Measurement
>> Protocol
>>
>>        (TWAMP) Light) and Simple Two-Way Active Measurement Protocol
>> (STAMP)
>>
>>        for Delay Measurement, and also uses the mechanisms defined in
>> this
>>
>>        document for Loss Measurement.  The procedure specified is
>> applicable
>>
>>        to SR-MPLS and SRv6 data planes and are used for both links and
>>
>>        end-to-end SR Policies.
>>
>>
>>
>>     Please note that it may take a couple of minutes from the time of
>> submission
>>
>>     until the htmlized version and diff are available at tools.ietf.org.
>>
>>
>>
>>     The IETF Secretariat
>>
>>
>>
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>>
>