In your previous mail you wrote:
Yes, it is strongly discouraged to define new extension. But if it
is necessary, it should not be forbidden.
=> good summary: now you have to prove a new extension header is really
necessary!
So it may be better to organize the informations to an extended
header, if it is necessary. It not only simplify the processing of
program, but also improve the efficiency of program.
=> I don't buy the argument: the processing of an option is not so more
expensive than the processing of an extension header. The only real
difference between options and extension headers is the length of an
option is more limited...
which is well suited for measurement since it is necessary to limit the
interference of the measurement data transported within the packet in
order to have a relevent measurement.
We developped an IPv6 measurement infrastructure based on the
utilization of Destination options. It works well and, since we only
transport the sending timestamp, we don't need a special extension.
I'll be happy to collaborate.
Best Regards,
Geraldine Texier
I propose to only ask for a (or a few) measurement option types,
leaving the internal layout to private experiments... Note a RFC
is needed to get an official option type.
Regards
Francis.Dupont at enst-bretagne.fr
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
Geraldine TEXIER
GET/ENST Bretagne - RSM Department
2 rue de la Châtaigneraie - CS 17607
35576 Cesson Sevigné Cedex- France
Tel: +33 299 127 038 - Fax: +33 299 127 030
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
