Subject: [OPSAWG] agenda requests for opsawg in Vancouver

From: [email-masked] (Scott O. Bradner)
Date: Tue, 6 Nov 2007 22:42:06 -0500 (EST)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/opsawg

---

From: "David Harrington" <[email-masked]>
Date: Wed, 7 Nov 2007 22:34:17 -0500

Hi,

We would like to request time for discussion of
draft-romascanu-netconf-datatypes-03.txt and
draft-li-mib-convert-xx.txt.

dbh

> -----Original Message-----
> From: Scott O. Bradner [mailto:[email-masked]] 
> Sent: Tuesday, November 06, 2007 10:42 PM
> To: [email-masked]
> Subject: [OPSAWG] agenda requests for opsawg in Vancouver
> 
>

---

From: KIKUCHI Yutaka <[email-masked]>
Date: Thu, 08 Nov 2007 13:25:48 +0900 (JST)

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.

---

From: KIKUCHI Yutaka <[email-masked]>
Date: Thu, 22 Nov 2007 14:45:52 +0900 (JST)

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.

---

From: KIKUCHI Yutaka <[email-masked]>
Date: Thu, 22 Nov 2007 18:58:44 +0900 (JST)

Folks,

> I am going to state the rest issues later.

The main change of the structure from the original I-D
is splitting it into two I-Ds, one for the requirements
and the other for the metrics and measurement method.
The first two issues are related to the requirements draft
draft-kikuchi-tunnel-measure-req-02.txt.

> 1. why tunnel specific?

The original draft did not describe the purpose of
measurement well, so we had improved the description
of section 3 "Motivations". The most important point
is that TSPs must maintain each one of flows with SLA.

> 2. when used? testing or all time?

The point did not exist explicitly in the original draft,
so the newest version has an explicit description
in the second paragraph of section 4 "Requirements".

The answer is "all time". All time for every tunnels
that you want to OAM in the real networks.
This requires the mechanism should be very lightweight,
so we introduce a new metrics for measurement
described in draft-kikuchi-passive-measure-01.txt.

The next issue refer this draft.

> 3. reuse IPPM metrics, do not produce a new one

The draft proposes a measurement mechanism with
sequence numbers. For scalability and make it lightweight,
measuring egress routers have only one register
that keeps next number of incoming packets.
Therefore, the algorithm can detect that a flow
is whether in-sequence or out-of-sequence,
but cannot accurately determine error reasons.

If we use the metrics duplicate, loss and reordering
defined in IPPM, the proposed mechanism must not
work well with the metrics.

We had used the words "duplicate", "loss" and "reordering"
in the older draft, but this use has confused the reader
and cause misunderstanding, so we named different names
to the similar metrics as "dup-train", "skipping" and "astern".

See section 2 "Metrics" of draft-kikuchi-passive-measure-01.txt
to see the metrics definition, the difference
from the legacy metrics and the detail reason.

> 4. sequence number overhead, happens fragmentation

Yes, sequence number field makes headers long
and enlarged packets may fragment.

But this issue is mostly independent from our proposal.
We do not aim to extend existing protocols but
just use protocols that already have sequence numbers.

See detail in section 4.5 "Header Information" of the
requirements draft draft-kikuchi-tunnel-measure-req-02.txt.

> 5. the use of "passive" seems not accurate

The issue may come from our algorithm uses sequence number
that seems to inject some extra information for measurement.
I think this method is completely passive because of the same
reason above. The measurement mechanism does not inject
any information into flows.

> 6. how this secured?

This issue is discussed in the "Security Considerations" sections
of both I-Ds since the original version.

Of course fraud sequence numbers cause the measurement error.
But I think we should not prepare additional security armour.

The first reason is such the responsibility should be done
by less under layers. The second reason is that new armours
may make other security issues and security holes.

The third reason is that it is difficult to let a disordered
flow seems to be in-sequence. It might be possible to let
a ordering flow seems to be out-of-sequence though,
the operator can easily detect such a trouble with the flow.

The last reason is not described in the I-D yet.

One more issue.
http://www1.ietf.org/mail-archive/web/opsawg/current/msg00014.html

Yes, I followed the suggestion to write the latest version.

Thank you very much for reading my long message.
Please give us any advice, comments and questions.

-- Best regards, Yu.

---

From: KIKUCHI Yutaka <[email-masked]>
Date: Mon, 26 Nov 2007 13:05:02 +0900 (JST)

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.