On Tue, 16 Oct 2007, Andrew McDonald wrote:
quoted text
> For why you don't want to packets to be forwarded, consider a simple
> example that applies to something like RSVP:
> - packet hits router, identified as potentially interesting from router
> alert option
> - packet passed to user space, confirmed as really interesting and
> processed
> - create new packet (based on the one that came in and the RSVP
> processing you've done) and send it out
>
> You don't want the original packet you received to be forwarded, only
> your new packet.

Router alert option on a hop-by-hop header means that every router on 
the path should process the option.

You did not mention the rationale why the it would be reasonable for a 
packet that would otherwise be forwarded by the Linux router and 
expected to be processed by every router on the path to be re-created 
at every step, and every user-space application have to do that.

In the specific case of RSVP packets, AFAIK (e.g., Path and PathTear 
messages), the content of the RSVP packet is expected to be the 
same at every hop.

Your argument might make sense in the case where the payload of the 
packet carrying router-alert option is expected to change at every 
hop.  I believe that's not the intent of any router alert options that 
I'm aware of.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html