Re: [ippm] Latest Updates to SR PM Drafts
Greg Mirsky <gregimirsky@gmail.com> Fri, 24 May 2019 02:07 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 0E3F712015B; Thu, 23 May 2019 19:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 vE_ESkVFqmhd; Thu, 23 May 2019 19:07:35 -0700 (PDT)
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 48F02120181; Thu, 23 May 2019 19:07:35 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id z1so1757890ljb.3; Thu, 23 May 2019 19:07:35 -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=JungtIHO84MRL0HKghMGvHfr3i49qmx6HoF+jMbZuwM=; b=qtsyKlSqjXvf/U9+N4Qr3FdugWvlPCGD7drxxv1hMHYbZyqlUZ/bqlbBJIM+T2Iv4c z/fhpYvBzAQY7hw4jEk7OroYQNa/ncNZA9vj3qdp98WlSLYzRNXVA35w4drxnm+p3v7E mm6hvBmh6bXucaGsuIyn7ZzwcH8k9SYP+UVeFXc9RKllvGJ/2MNQwdv03XVeB3tNqmLq mNAzOkD3LwSAfo2LJMt337xP0RV9K5VArk4GrkdJhHgLn0P9AYBnUygr9Whqgms4IY8w eakqZjw+T0Wu3Lm1VcmXZVbOZ5lImwjqMtzoLXr1xBCpXKaOwtoCKPALyUD4PdVqkTVP WJgw==
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=JungtIHO84MRL0HKghMGvHfr3i49qmx6HoF+jMbZuwM=; b=D8qEa5UBKyx9IODM6gXFWuSFENtn9q9ekTjJwvTCGGZ5NLaEzg66XIhqxI+2SGlhJh 2O1bs7k/zC++yOyZ3dFFeignpNCZ2/023Dm15uMfDmUz9G+KMlKqAhlGM+XwEgqS+pJF vwBU5CuHXZ+Zi3VCHjwTZk3v0fFf9PKFNRzEnKqkgkb6M2Uwu0PhVfYCQgAoEri0ibYT haCQU14V3v33rF9tFOsfrjIxv2J3Sc/NaFjYGJLVAxBDL7z0EpTWC9KZszf1rAYj9Izr yLr34BJsO0bL0wbAQScup+LAknuFvqszzhqvzP0/4OZ6VQpLw7vQ7jMKl4P8uM2HkS9/ +eyQ==
X-Gm-Message-State: APjAAAU3nAhwZOm5VCVN7x82Pe8b3qMNYD8cXreBlnixw/E+DiSRtTu6 kP5YmjZK+jzLV0tLtoHu95T4rlabgL57WKK59vA=
X-Google-Smtp-Source: APXvYqzyBUeN6+HYHcYczHVijyCm78Ldu4DnHLhxtoI9FQUhNsQCwSum04uP+6vXmCLgDetIk4XFqAF0AmAs2+7h8xY=
X-Received: by 2002:a2e:8588:: with SMTP id b8mr8714367lji.3.1558663653314; Thu, 23 May 2019 19:07:33 -0700 (PDT)
MIME-Version: 1.0
References: <6483D3B4-8C1B-4CE0-8701-376DB1BE92B4@cisco.com>
In-Reply-To: <6483D3B4-8C1B-4CE0-8701-376DB1BE92B4@cisco.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Thu, 23 May 2019 19:07:22 -0700
Message-ID: <CA+RyBmXGHS-BTKLuvPCUr2q98nK-8fCvB=sFA+oYCViJinsHiA@mail.gmail.com>
To: "Rakesh Gandhi (rgandhi)" <rgandhi@cisco.com>
Cc: "spring@ietf.org" <spring@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006156ff058998a9fc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/HwKWOj4_7s96o_1_ibdKJlrkVAE>
Subject: Re: [ippm] Latest Updates to SR PM Drafts
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: Fri, 24 May 2019 02:07:39 -0000
Hi Rakesh, and Authors, thank you for bringing the updates to the draft for the discussion. Please find my comments and questions below: - General. The draft title states that the underlying mechanism it uses is TWAMP. But the TWAMP, according to RFC 8545, is the union of TWAMP-Control and TWAMP-Test. Since the draft does not propose extensions to TWAMP-Control in support the new functionality, I believe it cannot be referred to RFC 5357 as its principal source. It might be referred to the Appendix I in RFC 5357 that describes the mode also referred to as TWAMP-Light. But because the Appendix has only Informational value, interoperability among the existing implementations of TWAMP Light, the one supporting this specification requires detailed analysis. (More on this issue further down.) - in Section 3.1 when describing the mechanism to demultiplex PM probes (use user-configured destination port numbers), you've noted "This approach is similar to the one defined in STAMP protocol [I-D.ippm-stamp]." Can you elaborate further in what part the STAMP specification uses user-configured destination port numbers at the Session-Reflector to demultiplex extensions. As I've suggested in the beginning of the discussion of this proposal, STAMP uses TLVs to extend the functionality of its base specification. As for the use of the destination port number at Session-Reflector, STAMP takes advantage by using UDP port 862 [RFC8545] as the default value. Thus STAMP Session-Reflector minimizes required provisioning. - Section 3.1.1 recommends the use of PTP time stamp format following the procedures defined in RFC 8186. Please note, that for OWAMP, RFC 8186 defines an extension to OWAMP-Control protocol that allows negotiating the timestamp format. Without the use of the OWAMP-Control, the Session-Receiver that does not support RFC 8186 would assume that the format in the received DM Probe Query message is NTP and will miscalculate the metrics. - On the use of the Authenticated mode in DM. Note that RFC 4656 requires the support only of HMAC-SHA1. Also, what is the size of the block for the authentication of the message? - More on Authentication of DM: - What is the format of the authenticated query - what is the format of the authenticated (and unauthenticated as well) response message - what is the difference between the proposed DM query/response and RFC 5357 Session-Sender and Session-Reflector packets? From reading Section 3.2, it appears that the DM Response message format is as defined for the Session-Reflector in RFC 5357. Can that be expressed in one-liner without the unnecessary complication of introducing DM query, that is the duplicate of what already defined in RFC 5357? - Section 3.1.2 has, what I believe, significant interoperability with TWAMP-Light issues: - The format is not backward compatible and, without the use of TWAMP-Control, the Session-Sender is not aware of the set of functions supported by the remote implementation of TWAMP-Light. The use of the explicitly configured UDP port number on a Session-Reflector is very standard on TWAMP-Light implementations in the field. How do you propose to discover the set of functions that the targetted Session-Reflector supports? - Another question. Assuming that the Session-Reflector that does not support this specification validates the LM query packet and responds with the reflected packet but formatted according to RFC 5357 (and possible extensions like described in RFC 6038 and/or RFC 7750), How the Session-Sender that receives such test packet be able to validate, parse, and use the information? - I'm puzzled how the proposed in Section 3.2.2.1 the new extension to STAMP is related to the rest of the document that, as I read it, is based on OWAMP/TWAMP, but not STAMP specifications. How the new TLV, registered in STAMP-related registry, will be used in, for example, DM Query message, which is the same as OWAMP Session-Sender Test packet? - The LM measurement mode, please correct me if I'm mistaken, uses what is usually called Direct Loss Measurement. It is well-known from, for example, ETH-LM in G.8013/Y.1731. Also, draft-xiao-ippm-twamp-ext-direct-loss described the full set of extensions to TWAMP (TWAMP-Control and TWAMP-Test) in support of the Direct Loss Measurements. But I couldn't find any reference to that work that preceded this draft. Much appreciate your consideration of my comments and questions. I am looking forward to our discussion on email and in Montreal. Regards, Greg On Tue, May 21, 2019 at 3:08 PM Rakesh Gandhi (rgandhi) <rgandhi@cisco.com> wrote: > Hi WG, > > > > We have posted following updates to SR PM drafts to address various review > comments and suggestions. > > > > > --------------------------------------------------------------------------------------------------------------------------------------------- > > > > draft-gandhi-spring-twamp-srpm > <https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/> > > > > This draft defines SR PM using TWAMP RFC 5357, as well as new message for > direct-mode loss measurement. The latest version of the draft has been > updated with: > > 1. Mach Chen joined as a co-author. > 2. Remove term In-band probes and add as “probes sent on congruent > path with data traffic” in Section 2.2. > 3. Add packet counter format flags in LM message in Section 3. > 4. Add Checksum complement in Section 3. > 5. Define Return Path TLV for two-way measurement mode in Section > 3.2.2.1. > 6. Add Loopback measurement mode in Section 3.2.3. > 7. Add Path Segment ID in Figure 3. > 8. Add details for P2MP SR Policy in Section 4. > 9. Include OWAMP and TWAMP use HMAC-SHA1 for integrity protection in > Section 7. > 10. Cleanup/editorial changes. > > > > Open Items: > > - None > > > > > --------------------------------------------------------------------------------------------------------------------------------------------- > > > > draft-gandhi-spring-rfc6374-srpm-udp > <https://datatracker.ietf.org/doc/draft-gandhi-spring-rfc6374-srpm-udp/> > > > > This draft defines SR PM using IP/UDP encap for RFC 6374. The latest > version of the draft has been updated with: > > 1. Remove term In-band probes and add as “probes sent on congruent > path with data traffic” in Section 2.2. > > 2. Add loopback measurement mode in Section 3.2.3. > > 3. Add Checksum complement in Section 3.3. > > 4. Add Path Segment ID in Figure 3. > > 5. Add details for P2MP SR Policy in Section 4. > > 6. Cleanup/editorial changes. > > > > Open Items: > > - None > > > > > --------------------------------------------------------------------------------------------------------------------------------------------- > > > > draft-gandhi-spring-rfc6374-srpm-mpls > <https://datatracker.ietf.org/doc/draft-gandhi-spring-rfc6374-srpm-mpls/> > > > > This informational draft reviews SR PM for MPLS data plane using RFC 6374. > The latest version of the draft has been updated with: > > 1. Remove term In-band probes and add as “probes sent on congruent > path with data traffic” in Section 2.2. > 2. Add Return Path TLV for two-way measurement mode in Section 3.3.2.1. > 3. Add loopback measurement mode in Section 3.3.3. > 4. Add Path Segment ID in Figure 4. > 5. Add block number TLV in Section 5.1.1. > 6. Add details for P2MP SR Policy in Section 6. > 7. Add details for ECMP in Section 7. > 8. Cleanup/editorial changes. > > > > Open Items: > > - None > > > > > > Thank you everyone for your review comments and suggestions on these > drafts. Welcome your additional feedbacks. > > > > Thanks, > > Rakesh (on behalf of co-authors and contributors) > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm >
- [ippm] Latest Updates to SR PM Drafts Rakesh Gandhi (rgandhi)
- Re: [ippm] Latest Updates to SR PM Drafts Greg Mirsky
- Re: [ippm] Latest Updates to SR PM Drafts Rakesh Gandhi (rgandhi)