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

Greg Mirsky <gregimirsky@gmail.com> Mon, 02 March 2020 16:10 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA473A09DF; Mon, 2 Mar 2020 08:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKFZoQiZSwBE; Mon, 2 Mar 2020 08:09:58 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC6B3A09DD; Mon, 2 Mar 2020 08:09:57 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id a10so27058ljp.11; Mon, 02 Mar 2020 08:09:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q37bQyCSuPNX16krK/5rK85RbVz7SQ/CWe4aEpZvEJU=; b=IkceiStBVxe+LEqIvW8jVkntnRXc0tSOH4xYtW/kfdaGa+70eRkOY3I/v/Z/LaLSPO IgJ1SaI/8IaOu8GB5D0j3Gvqhl7oaa4bFkq46scgHheIPAxdm8X85l3tSZWFJqbP6ypT VBXyucxQrTNyK3JeJpH12zSspOu1UtpctQaMIysccri4GhEUfjyCbHl6crYmKy82z3bN qY5Iom1ra/Kfuv/a6IwaZSYFo29tGTZjvgfylqUdSd0c+tctPK3Rn+udtmdALh0/yRCO PWMTW55hZ+o8SKz7aruOcpf+qMDRUU4XXfypByVuovjAv4OsQqyXlaPF0TFNe1Haf2HM wBzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q37bQyCSuPNX16krK/5rK85RbVz7SQ/CWe4aEpZvEJU=; b=n/j1XXvVva9EI1u3R5wH7ve9KNTP3E1vtLx+b1OnMuXPpprkCD9MYBjxR0zCzWFc/M gxc4ttD7PHwqVFZGC+Ce8A3zLd3MIREVdl0zuEmAxVd/0uSMfjhTnDF1kBDQXA8surt6 K4oRbvpN45DRFNpqania/vw3BXfj87PiIQEjZ/PAMkrXI3SWrWG8Uam2OuIj8HWfzgjZ udY2IQJOLR1FE4P0eNiNPDoRGk4lHC/zGOYS22mxiMZZK/x6W+0NoRnnxA0Vi+4tEUkE vPLUepzMLX6eLafgJ3GrQ/podVZgO4+O5M0kvosaUe3sCa5R8yZwJFWUC3ybwDfr8oIk NcrA==
X-Gm-Message-State: ANhLgQ1YRXW5W08qj0J9hFIgKeq6obrU4RmLvU/Kum5ormyZQM8319Kb PwIocgzwGb3LQSbIg/kGDP9jf9rwknRJJvQ8TaE=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsNdphj0jvZVMy2NOsxJL/EOHapNnFcnDMwhcZX?= =?utf-8?q?WGLPG/NGGrE/H4MTi1pOcGYMrnagcZN9nPOmFbggaiy42o0=3D?=
X-Received: by 2002:a2e:9e43:: with SMTP id g3mr11966799ljk.37.1583165395364; Mon, 02 Mar 2020 08:09:55 -0800 (PST)
MIME-Version: 1.0
References: <CAMZsk6f9Nuui4cU+fwoqLZcq6Bz21Z0cd4q5RwMypNZxF1Mk6g@mail.gmail.com>
In-Reply-To: <CAMZsk6f9Nuui4cU+fwoqLZcq6Bz21Z0cd4q5RwMypNZxF1Mk6g@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 2 Mar 2020 17:09:43 +0100
Message-ID: <CA+RyBmWgAJHYke_J92f=8oxWwbf7=qF-oS4NYhzgTZ1mFxmvvg@mail.gmail.com>
To: Rakesh Gandhi <rgandhi.ietf@gmail.com>, IETF IPPM WG <ippm@ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>, spring-chairs@ietf.org
Cc: spring <spring@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000002f085059fe16b36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/bGTsJmJ5-eC3B-mfDCXAFiCAC3o>
Subject: Re: [ippm] [spring] Updates to draft-gandhi-spring-twamp-srpm-05.txt
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Mar 2020 16:10:01 -0000

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
>