Re: [v6ops] IPv6 Diagnostic Option

Arturo Servin <arturo.servin@gmail.com> Fri, 22 July 2011 11:37 UTC

Return-Path: <arturo.servin@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27E221F87BD; Fri, 22 Jul 2011 04:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
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 gd6JFf3YtSrx; Fri, 22 Jul 2011 04:37:13 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB2621F8793; Fri, 22 Jul 2011 04:37:12 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1759066qwc.31 for <multiple recipients>; Fri, 22 Jul 2011 04:37:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=w3JeqfAVcBJtcInSOvBhvYsRvx/fY4TXfWKVO1WO9cM=; b=mQLC6MQsQPSBy6GBFv32g6dGPstyG4EsD5mG2arIKgl9ij01B0rT41/d/5Ud3mO9qM oNQ191NQoVm37rIx0Yh+AH/w2yxRynKKjFfyBKN4cXSn5QJ5Dn7slkEXuhjacG7qdKdv 1/ik51m0+dadZHMhzexpYocvtsNAa4nQSkDvI=
Received: by 10.224.179.195 with SMTP id br3mr1205083qab.284.1311334632355; Fri, 22 Jul 2011 04:37:12 -0700 (PDT)
Received: from [192.168.1.101] (r186-48-209-197.dialup.adsl.anteldata.net.uy [186.48.209.197]) by mx.google.com with ESMTPS id w12sm856284qct.12.2011.07.22.04.37.09 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 22 Jul 2011 04:37:11 -0700 (PDT)
Subject: Re: [v6ops] IPv6 Diagnostic Option
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Arturo Servin <arturo.servin@gmail.com>
In-Reply-To: <4E292DF2.5000607@kit.edu>
Date: Fri, 22 Jul 2011 08:37:06 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B486090-29D8-41C9-87B2-01D5F8D9FECE@gmail.com>
References: <1311309532.77035.YahooMailClassic@web2814.biz.mail.ne1.yahoo.com> <4E290D99.3030300@kit.edu> <CAAedzxr5JrXKfRAfo+e7CwkvvFBRju3n8CL2xpRvhaS7hcjPng@mail.gmail.com> <4E292DF2.5000607@kit.edu>
To: IPv6 Operations <v6ops@ietf.org>
X-Mailer: Apple Mail (2.1084)
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2011 11:37:13 -0000

Nalini

	Basically I agree with what others said.

	If there were any reason for not using the flow label, I think you should state it very clearly in the document. 

Regards,
.as

On 22 Jul 2011, at 04:59, Roland Bless wrote:

> Hi Erik,
> 
> On 22.07.2011 08:35, Erik Kline wrote:
>>> I don't think that your proposed solution is necessary, since
>>> IPv6 has the Flow Label, that - if set by the source - may be
>>> very well suited for your purpose (tracking flows along a path).
>>> Please see http://datatracker.ietf.org/doc/draft-ietf-6man-flow-3697bis/
>>> for more details.
>> 
>> I also think use of the flowlabel will prove operationally simpler.
> 
> Yes, fully agree since
> a) the Flow Label is part of the standard common IPv6 header, thus
>   always present and easier to process (even in the fast path) as
>   you also pointed out.
> b) Useful Flow Label support in end-systems (i.e., setting the Flow
>   Label correctly) is more likely than support for this newly
>   suggested additional option, once it would have been adopted.
> c) it is really unclear how you would enable the use of the proposed
>   option in end-systems on demand. In case of debugging a network
>   problem you need to enable this option later, if not too late.
> 
> Regards,
> Roland
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops