> 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
> 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.
> 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
> moreexpensive than the processing of an extension header. The only
> realdifference between options and extension headers is the length
> of an
> option is more limited...
> 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.
==>Yes, if there are only measurement options in destination header,
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. It may exhaust more time.
I think that we have the same idea, but there are some little differences.
We can collaborate together.
Regards.
***************************************************************************************
Declaration:
This email and any files transmitted with it are confidential and intended
solely for
the use of the individual or entity to whom they are addressed. If you have
received
this email in error please notify the sender. Any offers or quotation of
service are
subject to formal specification. Errors and omissions excepted. Please note
that any
views or opinions presented in this email are solely those of the author and do
not
necessarily represent those of Huawei Technologies Co. Ltd.. Finally, the
recipient
should check this email and any attachments for the presence of viruses.
Huawei Technologies Co. Ltd. accepts no liability for any damage caused by any
virus transmitted by this email.
**************************************************************************************
----- 原邮件 -----
从: Francis Dupont <[EMAIL PROTECTED]>
日期: 星期二, 十月 25日, 2005 下午9:51
主题: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00
> 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
> reallynecessary!
>
> 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
> moreexpensive than the processing of an extension header. The only
> realdifference between options and extension headers is the length
> of an
> option is more limited...
> 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
>
> [EMAIL PROTECTED]
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
