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