Subject: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00

From: zhangjian 24185 <[email-masked]>
Date: Thu, 27 Oct 2005 10:17:22 +0800

> 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-masked]>
日期: 星期二, 十月 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-masked]
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 27 Oct 2005 11:21:50 +0200

=> I don't understand at all why this argument doesn't apply to options!

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

=> the main difference is we are only using options...

Regards

---

From: Geraldine Texier <[email-masked]>
Date: Thu, 27 Oct 2005 15:51:27 +0200

I send you a link to a the Thesis document of Joel Corral, a PhD that 
participated to the development of the measurement platform based on the 
IPv6 destination option, I think you will find interesting things there.

http://www.rennes.enst-bretagne.fr/~jcorral/these/
you will find the PDF at the end of the page.
Regards
Geraldine texier

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

---

From: Geraldine Texier <[email-masked]>
Date: Thu, 27 Oct 2005 15:51:43 +0200

-- 
Geraldine TEXIER