Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)

Greg Mirsky <gregimirsky@gmail.com> Thu, 26 September 2019 15:08 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 472F212088D; Thu, 26 Sep 2019 08:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.755
X-Spam-Level:
X-Spam-Status: No, score=-0.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_NONE=-0.0001, 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 MMPF1EHi-Q7O; Thu, 26 Sep 2019 08:08:29 -0700 (PDT)
Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 1BE7C12088E; Thu, 26 Sep 2019 08:08:23 -0700 (PDT)
Received: by mail-lj1-x229.google.com with SMTP id q64so2529981ljb.12; Thu, 26 Sep 2019 08:08:23 -0700 (PDT)
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=bFzD0C0CHy1rasABY/DenB8BTZUAKVXrbLHTTN0kAc4=; b=PjGX3m//IXfvOtZR36NWVeFwFyk2AaScXyKi2mlzyemtWauQTmGIZiq3wyPADulKJD sa9crB4Erteb5FtdUyQ+RIBf3q95MDnwNJY7+3WKUBycPsgeXA0Uxs13DR8o3NGlPuhs 6QfSQEysNSkeNsAiFzSg44Gp9C3LmCXBSnnmbkO3NNMJHM2zuJFZIuEsaWods/W63UY1 3Cu+2Mz/dsvn7LirNOsMg6wGx1BpWyoaFPtFaAg1qQlkwLv3p/I2bqlEhXxusGNdr+k6 QIJkwEJ7Xdpz1+tG3p9SC4KuYtT4e5CzHmE08NtjTTq8sM8+RHGF7IddKzySKPFYUZWg CdtQ==
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=bFzD0C0CHy1rasABY/DenB8BTZUAKVXrbLHTTN0kAc4=; b=BYRDLAFY6vr/JJionyEwLk7ckKSctE82JwJPDewa62EJkmUD0yW2SpbEhEult9ABSr 5IKjmiZeuJHIAYaozA4TS+EJCusbIboTEAVpFImYmRHszQkjsNQJPMt0Ms38NmZZ2/8i C3C3947w4dkDQPt+mfCi99ugE+qLl3xueBgTeEEDPzdvJ91Rmk/ojBdT7Ntccn44SHeo 7lkwDziCCUorRJEBfDK2iBt+nuDMbUTVg2CHnm0cKvUEl9NCUqkhZ2BF3YxKhUQtWRt4 Im9QNkP2CYyCCDl5XURr2ZCpctFE3eI2+SaVZrRk4SFRq27JildwEf693MepFB7jr0+X 9s7w==
X-Gm-Message-State: APjAAAWGMwmyUuzaZIkfEM2nlaUUWqXrQRIDEtEZhVpUSWMkhLT/v1tO 3LioA97yoU5d6ajMMTLcv9DKzA0Tg1+axV1rlkg=
X-Google-Smtp-Source: APXvYqy+RqrL3Rd1f0U0gXY9Yrz6/tT7cQj1Qxf63H9JB+K93GRuSsevk3VvP9JyNs5LAifQ+8ounzCu5pFTPFrcqSI=
X-Received: by 2002:a2e:5d98:: with SMTP id v24mr3097616lje.56.1569510501099; Thu, 26 Sep 2019 08:08:21 -0700 (PDT)
MIME-Version: 1.0
References: <156760524845.22816.16339950342338392164.idtracker@ietfa.amsl.com> <CA+RyBmUy-_ETfaPWoYivcWa0S3De4dcn9=Wb47M7x0vSfEsjYQ@mail.gmail.com> <06fcd3bea80067202534aa70857194b2e4335d3f.camel@ericsson.com> <CA+RyBmUowr39bRBDv1g35f-rJve-whkscd0ht17cjJA5-rWixQ@mail.gmail.com> <ed5f1afb634e8c0d39cdb6c2a52ad9e2ab459285.camel@ericsson.com> <CA+RyBmU08iGsqK9M9Vyq5wgs9UKQ7Q7c1zg_0j4u4X_48jOHGw@mail.gmail.com> <d87ce9b28bc7649875a1e5faff975e899f4609c9.camel@ericsson.com>
In-Reply-To: <d87ce9b28bc7649875a1e5faff975e899f4609c9.camel@ericsson.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 26 Sep 2019 08:08:10 -0700
Message-ID: <CA+RyBmUwRvaaXPZV8NM2by4=jmKesdSkyzA2sJ6QcR8Xa8C=Og@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "tal.mizrahi.phd@gmail.com" <tal.mizrahi.phd@gmail.com>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e3b35a05937623be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/u4x6hoEJVx7Lpq_qgZwq7L98jeY>
Subject: Re: [ippm] Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)
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: Thu, 26 Sep 2019 15:08:36 -0000

Hi Magnus,
thank you for all your comments, discussion, and patience.

Kind regards,
Greg

On Thu, Sep 26, 2019 at 1:41 AM Magnus Westerlund <
magnus.westerlund@ericsson.com>; wrote:

> Hi Greg,
>
> This clarifies it sufficiently. I have cleared my discuss.
>
> Thanks
>
> Magnus
>
> On Tue, 2019-09-24 at 13:39 -0700, Greg Mirsky wrote:
> > Hi Magnus,
> > a new section, Operational Considerations, has been added to address
> Barry's
> > DISCUSS:
> >
> > 5.  Operational Considerations
> >
> >    STAMP is intended to be used on production networks to enable the
> >    operator to assess service level agreements based on packet delay,
> >    delay variation, and loss.  When using STAMP over the Internet,
> >    especially when STAMP test packets are transmitted with the
> >    destination UDP port number from the User Ports range, the possible
> >    impact of the STAMP test packets MUST be thoroughly analyzed.  The
> >    use of STAMP for each case MUST be agreed by users of nodes hosting
> >    the Session-Sender and Session-Reflector before starting the STAMP
> >    test session.
> >
> >    Also, the use of the well-known port number as the destination UDP
> >    port number in STAMP test packets transmitted by a Session-Sender
> >    would not impede the ability to measure performance in an Equal Cost
> >    Multipath environment and analysis in Section 5.3 [RFC8545] fully
> >    applies to STAMP.
> >
> > Would it address your concern?
> >
> > The new version of the draft has been published. It includes all the
> updates
> > we've discussed.
> >
> > Much appreciate your consideration of the new version, comments, and
> > questions.
> >
> > Kind regards,
> > Greg
> >
> > On Mon, Sep 16, 2019 at 8:29 AM Magnus Westerlund <
> > magnus.westerlund@ericsson.com>; wrote:
> > > On Wed, 2019-09-11 at 11:33 -0700, Greg Mirsky wrote:
> > > > Hi Magnus,
> > > > thank you for clarifications and further detailing your comments,
> > > > questions. Please find my answers and notes below in-lined under the
> > > > GIM2>> tag.
> > > >
> > > > Regards,
> > > > Greg
> > > >
> > > > On Wed, Sep 11, 2019 at 12:53 AM Magnus Westerlund <
> > > > magnus.westerlund@ericsson.com>; wrote:
> > > > > Hi Greg,
> > > > >
> > > > > Thanks for the reply. See inline for my comments and response.
> > > > >
> > > > >
> > > > > On Tue, 2019-09-10 at 12:43 -0700, Greg Mirsky wrote:
> > > > > > Hi Magnus,
> > > > > > thank you for the review and thoughtful, pointed questions.
> > > > > Please
> > > > > > find my answers in-line under GIM>> tag.
> > > > > >
> > > > > > Regards,
> > > > > > Greg
> > > > > >
> > > > > > On Wed, Sep 4, 2019 at 3:54 PM Magnus Westerlund via Datatracker
> > > > > <
> > > > > > noreply@ietf.org>; wrote:
> > > > > > > Magnus Westerlund has entered the following ballot position for
> > > > > > > draft-ietf-ippm-stamp-07: Discuss
> > > > > > >
> > > > > > > When responding, please keep the subject line intact and reply
> > > > > to
> > > > > > > all
> > > > > > > email addresses included in the To and CC lines. (Feel free to
> > > > > cut
> > > > > > > this
> > > > > > > introductory paragraph, however.)
> > > > > > >
> > > > > > >
> > > > > > > Please refer to
> > > > > > > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > > > > > > for more information about IESG DISCUSS and COMMENT positions.
> > > > > > >
> > > > > > >
> > > > > > > The document, along with other ballot positions, can be found
> > > > > here:
> > > > > > > https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -------------------------------------------------------------
> > > > > ----
> > > > > > > -----
> > > > > > > DISCUSS:
> > > > > > > -------------------------------------------------------------
> > > > > ----
> > > > > > > -----
> > > > > > >
> > > > > > > Two very much discussing discusses. However, I would really
> > > > > like to
> > > > > > > hear the
> > > > > > > answer to these concerns before clearing.
> > > > > > >
> > > > > > > 1. Section 4.3: Is the HMAC field size of 16 bytes hard coded?
> > > > > If
> > > > > > > there ever
> > > > > > > would exist a need to deploy another integrity solution, even
> > > > > if
> > > > > > > the actual
> > > > > > > algorithm used to construct the tag can be agreed by the
> > > > > > > management, there
> > > > > > > appear to exist a hard look in to use 16-byte tags. Have this
> > > > > issue
> > > > > > > been
> > > > > > > considered?
> > > > > >
> > > > > > GIM>> Indeed, this specification defines the use of only one
> > > > > > algorithm and only 16 bytes-long HMAC field. Your question
> > > > > prompted
> > > > > > the discussion among authors and we believe that in a future
> > > > > > specification it would be feasible to extend supporting a number
> > > > > of
> > > > > > algorithms and different lengths of HMAC field both being defined
> > > > > > through extension to STAMP YANG data model.
> > > > >
> > > > > So if I understand this (taking a discussion with Mirja about
> > > > > keeping
> > > > > things as simple as possible) the solution is to basically is when
> > > > > need
> > > > > arises define a new STAMP version, and then use YANG to coordinate
> > > > > which version is used for the measurement. If that is a correct re-
> > > > > interpretation of your response then I am fine with it.
> > > >
> > > > GIM2>> The direction from the WG was to keep the base specification
> > > > as simple  as possible (and that was the reason to split TLV
> > > > extensions into a separate document).
> > >
> > > Yes, understood.
> > >
> > > > > > >         2. Section 6:
> > > > > > >         The possible impact of the
> > > > > > >    STAMP test packets on the network MUST be thoroughly
> > > > > analyzed,
> > > > > > > and
> > > > > > >    the use of STAMP for each case MUST be agreed by all users
> > > > > on
> > > > > > > the
> > > > > > >    network before starting the STAMP test session.
> > > > > > >
> > > > > > >         I assume some potential issues are know, shouldn't they
> > > > > > > really be
> > > > > > >         listed here in the security consideration to further
> > > > > > > motivate why the
> > > > > > >         analysis needs to happen.
> > > > > >
> > > > > > GIM>> This is in reference to using numbers from the User range
> > > > > as
> > > > > > the destination port number. Would adding the reference to the
> > > > > case
> > > > > > of using the port numbers from the User range address your
> > > > > concern?
> > > > > > Or rather refer to Section 4, as it includes more discussion
> > > > > (see
> > > > > > below)?
> > > > >
> > > > > Okay, I don't really care where the discussion happens. But I don't
> > > > > find any real discussion and listing of the concerns with using
> > > > > user or
> > > > > dynamic ports for STAMP Sessions? With the formulation you use, I
> > > > > would
> > > > > expect at least some list of potential concerns that needs to be
> > > > > evaluated in the context of the particular usage of STAMP.
> > > >
> > > > GIM2>> Per Berry's suggestion, I'm adding a new section, Operational
> > > > Considerations, to list possible scenarios and possible issues with
> > > > using destination ports from the User range and from the Dynamic
> > > > range. I hope to finish it in a couple days. Will share on this
> > > > discussion thread promptly.
> > >
> > > Great!
> > >
> > > Looking forward to review it when written.
> > >
> > > > > > >
> > > > > > > -------------------------------------------------------------
> > > > > ----
> > > > > > > -----
> > > > > > > COMMENT:
> > > > > > > -------------------------------------------------------------
> > > > > ----
> > > > > > > -----
> > > > > > >
> > > > > > >         1. Section 4:
> > > > > > >         Before using numbers from the User Ports range, the
> > > > > > > possible impact
> > > > > > >    on the network MUST be carefully studied and agreed by all
> > > > > users
> > > > > > > of
> > > > > > >    the network.
> > > > > > >
> > > > > > >         Is the above sentence missing to list an important
> > > > > > > assumption? Is the
> > > > > > >         assumption that by using the registred destination port
> > > > > an
> > > > > > > operator
> > > > > > >         that sees to much STAMP traffic can simply filter it
> > > > > out
> > > > > > > and that way
> > > > > > >         deal with the traffic, something which is not possible
> > > > > when
> > > > > > > using an
> > > > > > >         locally decided port? If that is the case, this
> > > > > assumption
> > > > > > > should
> > > > > > >         probably be noted.
> > > > > >
> > > > > > GIM>> That is a very good point but our primary motivation for
> > > > > this
> > > > > > cautionary note (or strong warning) was that by allowing STAMP to
> > > > > use
> > > > > > port numbers from the User range, ports that may be already
> > > > > assigned
> > > > > > to protocols, creates a DDOS attack vector. As for the filtering
> > > > > > STAMP traffic out, I think that even if the destination port is
> > > > > one
> > > > > > from the Dynamic range, for a relatively long test session it can
> > > > > be
> > > > > > filtered out.
> > > > >
> > > > > So if that is the only? concern then write it out. I would expect
> > > > > that
> > > > > the higher layer management protocol that creates a measurement
> > > > > session
> > > > > to actually ensure that the STAMP endpoint actually have the port
> > > > > numbers they attempt to use. Isn't that a reasonable requirement to
> > > > > put
> > > > > on the solution?
> > > >
> > > > GIM2>> Agree with your suggestion. Will put in the new section. If
> > > > STAMP is managed by a centralized system, whether it is proprietary
> > > > OSS/BSS or an orchestrator that uses YANG data models, the system
> > > > will be able to coordinate selection of port numbers on the Session-
> > > > Sender and Session-Reflector. But some systems may use EMS or CLI and
> > > > that is where human coordination may be required.
> > >
> > >
> > > Good, then likely this is resolved when your text is ready.
> > >
> > > > > My thinking with the filtering out concern was that in cases where
> > > > > one
> > > > > runs STAMP measurement sessions, if the measurement interfer with
> > > > > critical traffic an action for an on-path node that can actually
> > > > > identify the STAMP traffic was to filer it out. And that may be
> > > > > considered trivial when the well known port is used, but if a user
> > > > > or
> > > > > dynamic port is used, then that requries a managment system to
> > > > > provide
> > > > > the on-path node with the necessary information, i.e. 3/5 tuple for
> > > > > the
> > > > > STAMP flows.
> > > >
> > > > GIM2>> I think that a transit node can identify a flow as the STAMP
> > > > flow only if the destination port is the STAMP default UDP
> > > > destination port number, 862. In case a STAMP session has the
> > > > destination port number as one of port numbers from the User range,
> > > > IP/UDP encapsulation of STAMP packets would be indistinguishable from
> > > > packets originated by the application that is assigned that port
> > > > number. Thus, filtering out on only destination port number may
> > > > negatively affect service, legitimate service. Because of that, I
> > > > think that filtering will have to use more information. On the other
> > > > hand, if the test flow does not exceed agreed rate, then any
> > > > filtering test packets out, in my opinion, is counter-productive, as
> > > > it hides some issues in the networks rather than letting the OAM
> > > > tools to expose them, localize, and characterize.
> > >
> > > Ok. This was primarily to understand if this was in scope or not. But
> > > it sounds like this is not really in scope for how to manage it.
> > >
> > > > >
> > > > > > >         2. Section 3 and 4, and 4.1.1: What is a STAMP Session?
> > > > > Is
> > > > > > > that a
> > > > > > >         measurment session between one specific and sender and
> > > > > a
> > > > > > > specific
> > > > > > >         reflector for a time duration?  The defenition of the
> > > > > > > session do matter
> > > > > > >         if one intended to enable a single sender to use
> > > > > multiple
> > > > > > > reflectors,
> > > > > > >         and if that can be a single session or always multiple
> > > > > > > indepdendent
> > > > > > >         ones. Would appreciate a definition what a session is.
> > > > > If
> > > > > > > it is
> > > > > > >         possible to send STAMP traffic using a multicast or
> > > > > > > broadcast address
> > > > > > >         should be made explicit.
> > > > > >
> > > > > > GIM>> Your interpretation is correct, STAMP session is implicitly
> > > > > > defined as p2p. And that is what reflected in the STAMP YANG
> > > > > model.
> > > > > > Would the following text make it clearer:
> > > > > > NEW TEXT:
> > > > > >    In this document, a measurement session also referred to as
> > > > > >    STAMP session, is the session between one specific Session-
> > > > > Sender
> > > > > > and
> > > > > >    one particular Session-Reflector for a time duration.
> > > > >
> > > > > Yes, please include that definition. Question would it be clearer
> > > > > to
> > > > > replace ".. is the session betweeen .." with ".. is the bi-
> > > > > directional
> > > > > packet flows between .."?
> > > >
> > > > GIM2>> I agree, defining a session as a session makes is somewhat
> > > > repetitive. Thank you.
> > > > Below is the updated text:
> > > >    In this document, a measurement session also referred to as
> > > >    STAMP session, is the bi-directional packet flow between one
> > > > specific
> > > >    Session-Sender and one particular Session-Reflector for a time
> > > >    duration.
> > >
> > > Looks good to me.
> > >
> > > > >
> > > > > > >         3.  Section 4.1.1.:
> > > > > > >         Timestamp is eight octets long field.  STAMP node MUST
> > > > > > > support
> > > > > > >       Network Time Protocol (NTP) version 4 64-bit timestamp
> > > > > format
> > > > > > >       [RFC5905], the format used in [RFC5357].  STAMP node MAY
> > > > > > > support
> > > > > > >       IEEE 1588v2 Precision Time Protocol truncated 64-bit
> > > > > > > timestamp
> > > > > > >       format [IEEE.1588.2008], the format used in [RFC8186].
> > > > > > >
> > > > > > >         Is the clock source here something that may be relevant
> > > > > or
> > > > > > > simply
> > > > > > >         information the management functions should capture. I
> > > > > > > think there is a
> > > > > > >         similar issue to that of RTP faced when it comes to
> > > > > > > understand what the
> > > > > > >         timestamp actually represent and thus be used
> > > > > correctly.
> > > > > > > RTP clock
> > > > > > >         source specification is RFC 7273
> > > > > > >         (https://datatracker.ietf.org/doc/rfc7273/)
> > > > > >
> > > > > > GIM>> NTP and PTP encodings have a different interpretation of
> > > > > the
> > > > > > Fraction field of the Timestamp field. In my experience, PTP
> > > > > format
> > > > > > is native for the data plane, while NTP is more used at the
> > > > > control
> > > > > > plane. Original extension to TWAMP has been described in RFC
> > > > > 8186.
> > > > >
> > > > > I think you missunderstood. When I talk about clock source, I am
> > > > > actually referring to identifying the particular clock that the
> > > > > node
> > > > > use to derive the included timestamp from.
> > > > >
> > > > > And likely this is a moot point in this document where the clock
> > > > > source
> > > > > information belongs in the management layer, e.g. in the YANG data
> > > > > model.
> > > >
> > > > GIM2>> Timestamp Information TLV (draft-ietf-ippm-stamp-option-tlv)
> > > > provides information about the clock synchronization protocol and the
> > > > method by wich the timestamp has been acquired at a Session-
> > > > Reflector. We may extend it to list the name/locatior of the master
> > > > clock.
> > >
> > > Ok. sounds reasonable.
> > >
> > > > >
> > > > > > >         4. Section 4.1:
> > > > > > >            Because STAMP supports symmetrical test packets,
> > > > > STAMP
> > > > > > > Session-Sender
> > > > > > >    packet has a minimum size of 44 octets in unauthenticated
> > > > > mode,
> > > > > > > see
> > > > > > >    Figure 2, and 112 octets in the authenticated mode, see
> > > > > Figure
> > > > > > > 4.
> > > > > > >
> > > > > > >         The above text implies some potential for UDP payload
> > > > > size
> > > > > > > variability
> > > > > > >         for the STAMP packets. However, the actual definition
> > > > > > > appear to have
> > > > > > >         fixed sizes. Can you please clarify if I have missed
> > > > > > > something that
> > > > > > >         enables the STAMP packet to have variable size?
> > > > > >
> > > > > > GIM>> I think that the text can be improved by characterizing the
> > > > > > listed sizes as "base". The variable length of a test packet in
> > > > > STAMP
> > > > > > is supported by using Extra Padding TLV defined in draft-ietf-
> > > > > ippm-
> > > > > > stamp-option-tlv. Below is the proposed update:
> > > > > > OLD TEXT:
> > > > > >    Because STAMP supports symmetrical test packets, STAMP
> > > > > Session-
> > > > > > Sender
> > > > > >    packet has a minimum size of 44 octets in unauthenticated
> > > > > mode,
> > > > > > see
> > > > > >    Figure 2, and 112 octets in the authenticated mode, see Figure
> > > > > 4.
> > > > > > NEW TEXT:
> > > > > >    STAMP supports symmetrical test packets.  The base STAMP
> > > > > Session-
> > > > > >    Sender packet has a minimum size of 44 octets in
> > > > > unauthenticated
> > > > > >    mode, see Figure 2, and 112 octets in the authenticated mode,
> > > > > see
> > > > > >    Figure 4.  The variable length of a test packet in STAMP is
> > > > > > supported
> > > > > >    by using Extra Padding TLV defined in
> > > > > >    [I-D.ietf-ippm-stamp-option-tlv].
> > > > > >
> > > > > > With the new reference, should I-D.ietf-ippm-stamp-option-tlv be
> > > > > > moved to the Normative References list or may remain in the
> > > > > > Informative list?
> > > > >
> > > > > From my perspective, the fact that optional TLV may occur following
> > > > > the
> > > > > base headers appears quite important. Here comes a question of
> > > > > intention form the WG. Is it intended that one can have STAMP
> > > > > endpoints
> > > > > that do not even support receiving packets larger than the base?
> > > > > In other words there will be two main versions already now, one
> > > > > that
> > > > > supports some TLV and can at least handle the TLV skip forward and
> > > > > ignore the content and one that will throw a fit over the TLVs? If
> > > > > that
> > > > > is not the intention I think the fact that TLV's may occur should
> > > > > be
> > > > > moved into this specification and have it as a normative reference.
> > > >
> > > > GIM2>> Will move the reference to the Normative section. With TLV
> > > > being normative, I'd expect that the intelligent implementation of
> > > > this draft, of the base STAMP specification, will accept any valid
> > > > STAMP packet though not process extensions. But the base STAMP
> > > > Session-Reflector will return the base reflected packet.
> > >
> > > I think that is very reasonable approach. Are you close to complete the
> > > stamp-option-tlv document, or will the missref cause any issue?
> > >
> > > > > I guess the answer is that you have backwards comaptibility reasons
> > > > > for
> > > > > not allowing TLVs at all in some sessions, or?
> > > >
> > > > GIM2>> Yes, that and the principle "keep it simple".
> > >
> > > Thanks,
> > >
> > > To me it looks like with some text changes all my issues are addressed.
> > >
> > > Cheers
> > >
> > > Magnus Westerlund
> > >
> > >
> > > ----------------------------------------------------------------------
> > > Network Architecture & Protocols, Ericsson Research
> > > ----------------------------------------------------------------------
> > > Ericsson AB                 | Phone  +46 10 7148287
> > > Torshamnsgatan 23           | Mobile +46 73 0949079
> > > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> > > ----------------------------------------------------------------------
> > >
> > >
> --
> Cheers
>
> Magnus Westerlund
>
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------
>
>
>