Re: [ippm] draft-ietf-ippm-stamp-srpm - request for Early Allocation of IANA code-points

Greg Mirsky <gregimirsky@gmail.com> Fri, 08 July 2022 02:48 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 34488C15A739; Thu, 7 Jul 2022 19:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuJNmsUQU6pO; Thu, 7 Jul 2022 19:48:05 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261C3C14CF09; Thu, 7 Jul 2022 19:48:05 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id o7so5034165lfq.9; Thu, 07 Jul 2022 19:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Vdc5kS7ad9WggXcfAE8EvDs3WVetnqOCsBlyvWX9Z1Y=; b=dY/8AWanD63F5NmWyVQq1PMOUnP+6qKB6Syr7+LuagUu/yf2sjeng8zXfX2TGGCIwK cBpkCakufRUG3U6ROYe/Cj8fiXh67wx8oVHHYH9k9aLSon+AjhKTSagI3y3xrqzstNHq e4UVURnkuFDdVNZT3+PZmKG41K5dH31kYkmlFQxcW+hRjP/bjVCnI2ptsC2eNPBshSf1 giPrPxDcszmNG90kal/WwK2oO4z74TLis0IA5MxlS1lN/dbvdqrNrurEmfXGrxVhHgQo nIQpDBpCEySW2ptLfZ2z1XLwMBWufn+S450cjgHYq5vLAltYQFZV3t1fOrNkg/4yDRkZ 7e7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Vdc5kS7ad9WggXcfAE8EvDs3WVetnqOCsBlyvWX9Z1Y=; b=6aoc9XSxdmeIfr49PUhcyJZ4S/Zli8YjpvmQgChjhipq32sSFMgDKDN0iLbR5BRc/I qo5nHzCaPdjdAzGCY+ixZ4x5EvghixOks012bD5INFniEPllhCDnCOk0yHkUZYpwOtZm Fmra0QTCp742IQI4wjwSIE6cJRDBCPJ3QbkIbLwExnWDw71vtel1K+V+ivFJH20FODOD QZW54CTH0bj3hDW9WZgghYltTth07yQ6rH796qq0adDZjh1NTJLXyb/o2nN0u5/Nyxdh oWFGo59XPQ8GOep2mggi7UglM9ggK+fjqu/KJdGr8k3VMYSUhCMQxerv1o1HOhKsY7+c OVGg==
X-Gm-Message-State: AJIora+2g8VcYNXS24fD/XXiYpM20Em5tM2N3dirn0+bT8bJeETZ87zl 59/BuOwd1d3u++mfY2OyxMG4MJ4uY9DD4l1KuvE=
X-Google-Smtp-Source: AGRyM1set+PqQS92skMa4vI40tPWHXJ4DPTSKHK+z76tPZytJriHPjPCs+8IWtYoz0fjKGViuIeIl5+pTuJbwvZzGM0=
X-Received: by 2002:a05:6512:acc:b0:47f:769e:6aef with SMTP id n12-20020a0565120acc00b0047f769e6aefmr844241lfu.26.1657248482793; Thu, 07 Jul 2022 19:48:02 -0700 (PDT)
MIME-Version: 1.0
References: <165705657853.17384.36655641519543061@ietfa.amsl.com> <CAMZsk6dC9Ub3XG15Cj+fBCQSi2sQvoptt4JGiTVLR6QMEFknww@mail.gmail.com> <AM0PR07MB41310468009C354F4E3E1D3AE2839@AM0PR07MB4131.eurprd07.prod.outlook.com>
In-Reply-To: <AM0PR07MB41310468009C354F4E3E1D3AE2839@AM0PR07MB4131.eurprd07.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 07 Jul 2022 19:47:51 -0700
Message-ID: <CA+RyBmUkarenjEwCor=NiKwOix9Tbd43QMpTtY2oy5K_Q50HRw@mail.gmail.com>
To: Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>
Cc: Rakesh Gandhi <rgandhi.ietf@gmail.com>, IETF IPPM WG <ippm@ietf.org>, IPPM Chairs <ippm-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f1ab605e3423b03"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/V8Xrzud6MlcBH5hBvc-3n_zWyK4>
Subject: Re: [ippm] draft-ietf-ippm-stamp-srpm - request for Early Allocation of IANA code-points
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 08 Jul 2022 02:48:09 -0000

Hi Marcus and Rakesh,
thank you for reminding me to read and comment on the draft. Below, pelase,
find my notes and questions:

   - it is not clear how the Verification flag benefits operation. RFC 8762
   defines that

   By default, STAMP uses symmetrical packets, i.e., the size of the
   packet transmitted by the Session-Reflector equals the size of the
   packet received by the Session-Reflector.

Thus, a STAMP Session-Reflector that does not support a particular STAMP
Extension will return that TLV in the reflected packet unchanged or as all
zeros.


   - Furthermore, if an extended STAMP test packet includes multiple TLVs
   and some have the V flag set, then what is the behavior of the STAMP
   Session-Reflector?
   - It appears that the use case for the Destination Address TLV is based
   on the assumption of the particular encapsulation of the STAMP test packet
   in MPLS. Is there a document that defines how STAMP is used over an MPLS
   network (similar to what RFC 5884 is for BFD specification in RFC 5880)?
   Had MPLS WG discussed it and agreed to?
   - Also on the Destination Address TLV. RFC 8972 defined STAMP Session
   Identifier (SSID) that, in combination with the Source IP address, uniquely
   identifies the STAMP test session and is sufficient to demultiplex them.
   Hence, it is not clear why the Destination Address TLV is needed.
   - I've got a question about the behavior of a STAMP Session-Reflector if
   there's no Return Path TLV in the received STAMP test packet. And while I
   understand the concept of network programmability, I'd imagine that for the
   given STAMP test session, downstream and upstream paths must remain
   unchanged (at least are expected to be unchanged and a noticeable change in
   packet delay will probably be correlated to a change in paths). If my
   assumption is correct, it seems that defining the return path can be
   achieved through a local policy by identifying the STAMP test session using
   SSID and the Source IP address tuple.
   - In addition, a question about Figure 5. The Segment field is 32
   bit-long while an MPLS label - 20 bit-long. How an MPLS label is encoded in
   the Segment field?
   - And, finally, on the requested IANA actions. A new sub-registry Return
   Path Sub-TLV Type is requested in the document. As I understand the
   requested early IANA allocation, it is left outside for now. What is the
   rationale for that?

Regards,
Greg

On Thu, Jul 7, 2022 at 8:41 AM Marcus Ihlar <marcus.ihlar=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi Rakesh,
>
> Thank you for the request.
>
> Could you please verify that you are referring to both: Destination Node
> Address TLV and Return Path TLV?
>
>
>
> To the IPPM WG:
>
> If you strongly object to requesting an early allocation of the IANA
> codepoints in draft-ietf-ippm-stamp-srpm please let us know by replying to
> this email.
>
> Please also indicate the reason for your objection.
>
>
>
> BR
>
> Marcus
>
>
>
> *From:* Rakesh Gandhi <rgandhi.ietf@gmail.com>
> *Sent:* Wednesday, 6 July 2022 13:49
> *To:* IETF IPPM WG <ippm@ietf.org>
> *Cc:* IPPM Chairs <ippm-chairs@ietf.org>
> *Subject:* draft-ietf-ippm-stamp-srpm - request for Early Allocation of
> IANA code-points
>
>
>
> Hi Chairs,
>
>
>
> We like to request early allocation of the IANA code points to facilitate
> interop testing. Please let us know of the next steps.
>
>
>
> Thanks,
>
> Rakesh (for co-authors)
>
>
>
>
>
> On Tue, Jul 5, 2022 at 5:31 PM <internet-drafts@ietf.org> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP Performance Measurement WG of the IETF.
>
>         Title           : Simple TWAMP (STAMP) Extensions for Segment
> Routing Networks
>         Authors         : Rakesh Gandhi
>                           Clarence Filsfils
>                           Daniel Voyer
>                           Mach(Guoyi) Chen
>                           Bart Janssens
>                           Richard Foote
>   Filename        : draft-ietf-ippm-stamp-srpm-04.txt
>   Pages           : 17
>   Date            : 2022-07-05
>
> Abstract:
>    Segment Routing (SR) leverages the source routing paradigm.  SR is
>    applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6
>    (SRv6) forwarding planes.  This document specifies RFC 8762 (Simple
>    Two-Way Active Measurement Protocol (STAMP)) extensions for SR
>    networks, for both SR-MPLS and SRv6 forwarding planes by augmenting
>    the optional extensions defined in RFC 8972.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-srpm/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-04.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-srpm-04
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>