Subject: Re: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt

From: sreenatha <[email-masked]>
Date: Tue, 06 Mar 2012 10:15:02 +0530

Hi Joel,
  I am co-author of the draft. I will try to answer your query. 
 	"It seems likely to me that an efficient host implementation can
meet the 
existing requirement relative to sourcing a packet with such options 
without noticeable load.  So there does not seem any point in relaxing 
the requirement."
     As you said, efficient host implantation can meet the existing the
requirement. But not all host will meet the requirement. So we suggesting
solution, so that all host can be efficient in processing of the Hop-By-Hop
header in source node.
	
   "And technically, if the host puts in a strict source route, and the
first 
hop is not directly reachable, it really does need to drop it.  So 
keeping the existing text has a minor benefit."
    Currently Strict Source route option will not come under Hop-by-Hop
header. As we mentioned in the draft, only Jumbo-gram and MLd options apart
from the padding options can be inserted in Hop-By-Hop header.  Routing
header will deal the Source route functionality.  So our solution will not
affect if host puts in a strict source route mode.

Thanks-
B.Sreenatha Setty

Message: 5
Date: Mon, 05 Mar 2012 08:04:17 -0500
From: "Joel M. Halpern" <[email-masked]>
To: Tina TSOU <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: FW: New Version Notification for
	draft-tsou-6man-hbh-header-update-00.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

It seems likely to me that an efficient host implementation can meet the 
existing requirement relative to sourcing a packet with such options 
without noticeable load.  So there does not seem any point in relaxing 
the requirement.
And technically, if the host puts ina strict source route, and the first 
hop is not directly reachable, it really does need to drop it.  So 
keeping the existing text has a minor benefit.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Mar 2012 10:08:08 +1300

Hi,

> As we mentioned in the draft, only Jumbo-gram and MLd options apart
> from the padding options can be inserted in Hop-By-Hop header. 

I don't understand this statement. MLD is a subset of Router Alert,
and various other HbH options are defined:

0x26 Quick-Start [RFC4782]
0x7  CALIPSO [RFC5570]
0x63 RPL [RFC-to-be draft-ietf-6man-rpl-option]
0x1e (etc.) Experimental [RFC4727]

I don't think we can assert that none of these need to be
processed at the source without analysis, which is of course
impossible for the experimental values or for unknown future
options.

I also think that stating that Router Alert doesn't need
to be processed at the source is dubious. If the source
is acting as both a host and a router (e.g. in an Internet
Connection Sharing scenario), you would be courageous to
state that there is no case in which node in its role as
a router should look at a Router Alert that it set in its
role as a host.

It seems reasonable to state that implementors MAY omit
processing at the source, if and only if they know by
construction that no HbH option that requires local processing
is created elsewhere in the host stack. But even so, they need
the code to skip over the HbH extension header if present.
We cannot replace

   if HbH header present, skip to next header
by
   No-op

Regards
   Brian Carpenter