Re: [OPSAWG] agenda requests for opsawg in Vancouver
KIKUCHI Yutaka <yu@kikuken.org> Mon, 26 November 2007 04:04 UTC
Return-path: <opsawg-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVDP-0004Tr-D7; Sun, 25 Nov 2007 23:04:59 -0500
Received: from opsawg by megatron.ietf.org with local (Exim 4.43) id 1IwVDO-0004Tl-RS for opsawg-confirm+ok@megatron.ietf.org; Sun, 25 Nov 2007 23:04:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVDJ-0004TO-Iz for opsawg@ietf.org; Sun, 25 Nov 2007 23:04:53 -0500
Received: from umi.kikuken.org ([202.126.16.27] helo=ari.kikuken.org) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IwVDI-0003yR-13 for opsawg@ietf.org; Sun, 25 Nov 2007 23:04:52 -0500
Received: (qmail 12803 invoked from network); 26 Nov 2007 13:04:49 +0900
Received: from unknown (HELO localhost) (218.100.15.124) by umi.kikuken.org with SMTP; 26 Nov 2007 13:04:49 +0900
Date: Mon, 26 Nov 2007 13:05:02 +0900
Message-Id: <20071126.130502.83602870.yu@kikuken.org>
To: opsawg@ietf.org
Subject: Re: [OPSAWG] agenda requests for opsawg in Vancouver
From: KIKUCHI Yutaka <yu@kikuken.org>
In-Reply-To: <20071122.144552.44275045.yu@kikuken.org>
References: <20071107034206.00F7961B682@newdev.eecs.harvard.edu> <20071108.132548.94837533.yu@kikuken.org> <20071122.144552.44275045.yu@kikuken.org>
Organization: Kochi Univ. of Tech.
X-Mailer: Mew version 4.2.53 on Emacs 22.0.50 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: zin@jaist.ac.jp, satoru@ft.solteria.net, nagami@inetcore.com
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
Errors-To: opsawg-bounces@ietf.org
Hi, The chairs had also advised us to check the interest of people on the mailing list. Folks, please respond about your thought, e.g. interested or not, important or not, understandable or not and/or should be discussed here or not. Of course, negative responses are welcome. If so, could you append the reason after seeing the description below (and the I-Ds if possible)? Background: Overlay network techniques have increased and will increase because some applications require new functions that the legacy transports do not serve, i.e. to guarantee some quality, policy routing, mobility, multi-homing, and hiding structure of underlayers. The tunneling technologies support the overlay network concept, therefore the net people will possibly operate and manage plenty of tunnels as well as the legacy transports and the current IP networks. About the I-Ds: Our proposal aims to state one of basic tunnel OAM methods independently from specific tunnel techniques. The details are not described here but I am showing a typical use case of the drafts... 0. operators in an xSP (and/or an iDC)... 1. after setting up for watching every one of tunnel flows, 2. while working with other tasks and listening music with iPod, 3. to get an alarm on a failure of some tunnels, and 4. to check the reason whether equipment fault, route changed or the other. 5. The xSP will (or will not) refund money according as the SLA with the measured tunnels' quality. History and the current situation: We has been searching for an appropriate WG to discuss the proposal for a year. The first time we asked was in the OPS-area open meeting of 68th IETF because we thought the proposal was an operational issue. As you know, OPSAWG had been opened since the 69th IETF, so we also had a good opportunity to discuss our I-Ds there. Now the original draft had been splitted into two drafts, because the original draft was made from both requirements and one of their solutions. Now the requirements draft needs discussion to be improved and deployed, so we would like to discuss here. Note that the other I-D, had been splited from the original I-D and describing concrete metrics and method, had lost the place to discuss. I thought the new PMOL would accept any discussion of performance metrics that were not suitable to IPPM and BMWG, but it was my misunderstanding. This issue has still been discussed in the PMOL mailing list. -- Best Regards, Yu. > Hi, > > The chairs advised us that we should explain how the past suggestions > had been addressed here before the determination of the final agenda. > > The following are suggestions and questions already we received > (not in the appearance order). > 1. why tunnel specific? > 2. when used? testing or all time? > 3. reuse IPPM metrics, do not produce a new one > 4. sequence number overhead, happens fragmentation > 5. the use of "passive" seems not accurate > 6. how this secured? > 7. discusstion should be in IPPM > > The last one has been discussed in the PMOL mailing list. > I am going to state the rest issues later. > > Please see also for detail: > http://www1.ietf.org/mail-archive/web/opsawg/current/msg00015.html > http://www1.ietf.org/mail-archive/web/opsawg/current/msg00017.html > http://www1.ietf.org/mail-archive/web/opsawg/current/msg00018.html > http://www3.ietf.org/proceedings/07mar/minutes/opsarea.txt > http://www3.ietf.org/proceedings/07jul/minutes/opsawg.txt > > http://www.ietf.org/internet-drafts/draft-kikuchi-tunnel-measure-req-02.txt > http://www.ietf.org/internet-drafts/draft-kikuchi-passive-measure-01.txt > > -- Yu. > > > Hi, > > > > We would like to discuss about our I-D > > draft-kikuchi-tunnel-measure-req-02.txt > > ``Quality Measurement Requirements for Tunneling Protocols''. > > The newest version will be appeared later. > > > > -- Best Regards, Yu. > > > > > > > > this is a first call for timeslots on the opsawg session in Vancouver > > > > > > we are currently scheduled for tuesday afternoon from 1520 to 1720 > > > > > > Scott & Ted > > > > > > > > > > > > _______________________________________________ > > > OPSAWG mailing list > > > OPSAWG@ietf.org > > > https://www1.ietf.org/mailman/listinfo/opsawg > > > > > > _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www1.ietf.org/mailman/listinfo/opsawg
- [OPSAWG] agenda requests for opsawg in Vancouver Scott O. Bradner
- RE: [OPSAWG] agenda requests for opsawg in Vancou… David Harrington
- Re: [OPSAWG] agenda requests for opsawg in Vancou… KIKUCHI Yutaka
- Re: [OPSAWG] agenda requests for opsawg in Vancou… KIKUCHI Yutaka
- [OPSAWG] tunnel quality measurement I-Ds KIKUCHI Yutaka
- Re: [OPSAWG] agenda requests for opsawg in Vancou… KIKUCHI Yutaka