[OPSAWG] tunnel quality measurement I-Ds

[KIKUCHI Yutaka <[e-mail]>]

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.


> 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.


_______________________________________________
OPSAWG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/opsawg