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

From: zhangjian 24185 <[email-masked]>
Date: Tue, 25 Oct 2005 10:58:37 +0800

> => a new extension header is likely to be problematic today because
> many boxes on paths look at the contents of packets (even they should
> not at the exception of the header, the hop-by-hop option header and
> routing headers where they are intermediate destinations). So in fact
> the definition of new extension headers is strongly discouraged.

In IPv6 specification, optional internet-layer information is encoded in 
separate headers that may be placed between the IPv6 header and the upper-
layer header in a packet. So the boxes on paths must look at the extended 
header, such as hop-by-hop option header and routing headers. Yes, it is 
strongly discouraged to define new extension. But if it is necessary, 
it should not be forbidden.

> BTW I can't see why you need a new extension header: some options,
> in the hop-by-hop option header for hop-by-hop measurements and in
> the destination option header for other cases, should do the job and
> option types encode the behavior for unrecognized options, the 
> mutability,etc. We use here a measurement option without problems 
> (I can give
> some pointers to our measurement people).
Yes, it can do the same work. But if there are lots of kinds of 
information in an extended header, it is too complex for program 
to identify and process these informations. Further more, it may
be decreased the efficiency of program. 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.

Best 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]>
日期: 星期日, 十月 23日, 2005 上午0:22
主题: Re: [ipv6] Request for your comments: draft-jian-ipv6-meaheader-00

> In your previous mail you wrote:
> 
>   Would you mind give me some comments?
>   
> => a new extension header is likely to be problematic today because
> many boxes on paths look at the contents of packets (even they should
> not at the exception of the header, the hop-by-hop option header and
> routing headers where they are intermediate destinations). So in fact
> the definition of new extension headers is strongly discouraged.
> 
> BTW I can't see why you need a new extension header: some options,
> in the hop-by-hop option header for hop-by-hop measurements and in
> the destination option header for other cases, should do the job and
> option types encode the behavior for unrecognized options, the 
> mutability,etc. We use here a measurement option without problems 
> (I can give
> some pointers to our measurement people).
> 
> 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: Tue, 25 Oct 2005 15:51:30 +0200

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