In your previous mail you wrote:
> => good summary: now you have to prove a new extension header is
> reallynecessary!
==>There are many measurement methodologies, each has its own information
carried on packets. So it is necessary to provide a infrastructure for
these methodologies based on ipv6. Using this extended header, we can
perform the measurement without modify the packet. So it is a good idea.
=> I don't understand at all why this argument doesn't apply to options!
==>Yes, if there are only measurement options in destination header,
=> usually there is no destination header (in fact no extension
header at all) so this hypothesis is right (:-).
it may same as extended header when processing it. But if there are
lots kinds of options, each module should check every option to see
whether it should process the option.
=> be serious please: in all the codes I've seen (including mine) the
option processing is vectorized or in a C switch, i.e., the cost is
an indirect or direct indexed branch.
It may exhaust more time.
=> for next header it is always vectorized.
I think that we have the same idea, but there are some little differences.
=> the main difference is we are only using options...
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
