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

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.
   - 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?
   - 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.

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.

Regards,
Greg

On Fri, Jan 31, 2020 at 10:30 PM Rakesh Gandhi <rgandhi.ietf@gmail.com>
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, "internet-drafts@ietf.org"
> <internet-drafts@ietf.org> 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
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>