Re: Last Call: <draft-ietf-mboned-ssmping-08.txt> (Multicast Ping Protocol) to Proposed Standard

Tim Chown <tjc@ecs.soton.ac.uk> Tue, 05 July 2011 21:11 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A3421F899C; Tue, 5 Jul 2011 14:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUBZK9QXDXid; Tue, 5 Jul 2011 14:11:54 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 70C6D21F885C; Tue, 5 Jul 2011 14:11:50 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p65LBfNw012603; Tue, 5 Jul 2011 22:11:41 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk p65LBfNw012603
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1309900301; bh=KIr0cIoyaKRtt8L3cLYauLr/I5E=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=da6EPGupO6JmjYN6Vcx/lsLxNWkOmU2lo0GHdJMj+qtyc7sZRwQnHKV01i4e/HxgD 9DKxnprPrjA9PHYqJBgU7Gh3d6vpAoQH8nHayO9IgeI3LxFz0U0cK2qwYV2CKfZIOe 6N88b0rfkY70OTYsGcp3n4FcFopu6vEDJfhoamc0=
Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP id n64MBf0366144435Y0 ret-id none; Tue, 05 Jul 2011 22:11:41 +0100
Received: from [192.168.1.100] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id p65LAIhf007346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Jul 2011 22:10:19 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: Last Call: <draft-ietf-mboned-ssmping-08.txt> (Multicast Ping Protocol) to Proposed Standard
From: Tim Chown <tjc@ecs.soton.ac.uk>
In-Reply-To: <20110620175110.14625.38398.idtracker@ietfa.amsl.com>
Date: Tue, 05 Jul 2011 22:10:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-ID: <EMEW3|772969f9f078348e983706777abf5dbbn64MBf03tjc|ecs.soton.ac.uk|D17DB58C-6822-4192-B9F0-F9617CDBB4D1@ecs.soton.ac.uk>
References: <20110620175110.14625.38398.idtracker@ietfa.amsl.com> <D17DB58C-6822-4192-B9F0-F9617CDBB4D1@ecs.soton.ac.uk>
To: IETF Discussion <ietf@ietf.org>, MBONED WG <mboned@ietf.org>
X-Mailer: Apple Mail (2.1084)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=n64MBf036614443500; tid=n64MBf0366144435Y0; client=relay,ipv6; mail=; rcpt=; nrcpt=2:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: p65LBfNw012603
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Jul 2011 21:11:56 -0000

I think this draft specifies a very useful protocol, which we have used at our site and which has been a valuable multicast debugging tool.

The specification and implementations have evolved over maybe 5-6 years or so.  The implementations we've used have been of various stages of the protocol's development.  A student at our site implemented an earlier version of the protocol successfully.  I don't believe we've used a version at our site based on the spec in the final version of the text, so I can't comment on that specifically.

There are some parts of the text that I think indicate the protocol has evolved over a length of time; if it were rewritten from scratch it would probably be somewhat more compact, due to some level of repetition of aspects of the protocol.  However, I think it's more important to get the protocol published now, so I would support publishing it as is.  

The protocol is defined in a fairly loose way, but the core elements are tight enough for implementation.  This is reflected in the text at the start of Section 6.

I noticed one nit in terms of the client ID. In Section 2 the text says:
"At runtime, a client generates a client ID that is unique for the ping test.  This ID is included in all messages sent by the client."
Then later in the more detailed spec, the text says:
"A client SHOULD always include this option in all messages (both Init and Echo Request)."
I would have expected the inclusion of the Client ID to be a MUST, based on the earlier explanation.  If it is a SHOULD, the introduction text should say "this ID is usually included in all messages sent by the client".

It would be nice to consider mechanisms to discover 'public' ssmping test servers, but that's a separate text :)

Tim

On 20 Jun 2011, at 18:51, The IESG wrote:

> 
> The IESG has received a request from the MBONE Deployment WG (mboned) to
> consider the following document:
> - 'Multicast Ping Protocol'
>  <draft-ietf-mboned-ssmping-08.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2011-07-04. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
> The Multicast Ping Protocol specified in this document allows for
> checking whether an endpoint can receive multicast, both Source-
> Specific Multicast (SSM) and Any-Source Multicast (ASM).  It can also
> be used to obtain additional multicast-related information such as
> multicast tree setup time.  This protocol is based on an
> implementation of tools called ssmping and asmping.
> 
> 
> 
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/
> 
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-mboned-ssmping/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce