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
- IPv6 Diagnostic Option nalini.elkins
- Re: [v6ops] IPv6 Diagnostic Option Roland Bless
- Re: [v6ops] IPv6 Diagnostic Option Erik Kline
- Re: [v6ops] IPv6 Diagnostic Option Roland Bless
- Re: [v6ops] IPv6 Diagnostic Option Arturo Servin
- Re: [v6ops] IPv6 Diagnostic Option nalini.elkins
- Re: [v6ops] IPv6 Diagnostic Option Karl Auer
- Re: [v6ops] IPv6 Diagnostic Option Brian E Carpenter
- Re: [v6ops] IPv6 Diagnostic Option Roland Bless
- Re: [v6ops] IPv6 Diagnostic Option Karl Auer