Re: I-D ACTION:draft-rahman-rtg-router-alert-dangerous-00.txt

Magnus -


On Oct 20, 2008, at 4:52 AM, Magnus Westerlund wrote:

> Hi,
>
> Adding TSVWG and NSIS as "owners" of a protocol using RAO, or that
> consider using RAO.
>
> Thanks for producing the draft. I definitely think we need to document
> the IETF consensus on this. I don't wish anyone to have to go through
> the NSIS debate regarding RAO in the future.
>

DW: As you know this works comes directly from the NSIS debacle and  
we were volunteered as stuckkeys.


> I looked through this draft.
> http://www.ietf.org/internet-drafts/draft-rahman-rtg-router-alert- 
> dangerous-00.txt
>
> I reacted on the following sentence from Section 4:
>
>    A router SHOULD inspect Router Alert packets before sending them to
>    the "slow path" so that if the protocol to which a packet  
> belongs is
>    not enabled on the router or on the incoming interface (physical or
>    virtual), then the packet is dropped.
>
> Isn't this preventing use of RAO completely unless all nodes between
> source and destination supports RAO and that protocol? Isn't the right
> answer to not kick it into the slow path and simply forward it?
>

DW: It would be the right thing if those were the semantics of RA.


> To me it seems that this recommendation is death blow to any protocol
> already using RAO and completely preventing future use. To me it seems
> that the main issue with RAO is how its handling has been implemented.
> If one did the filtering of the option in fast path and used the alert
> option number to correctly filter for the applications and protocols
> present on the node then you would not get such amount of slow path
> packets. Then adding filtering behavior to prevent overloading the  
> slow
> path and this would work better than the alternative of not using RAO.

DW: TBH, the draft is meant to be as close to a death blow as  
possible while leaving a pinhole of hope for the savvy designer.


>
> I do have to question if you really consider 5 tuple filters pushing
> packets into the slow path and then determine if they are a protocol
> going to router or not, as a better option? To me it seems to have the
> same issues with overload.
>

DW: We can add this as we attempt in the document to state warnings,  
expectations and deployment behavior. If you think adding a paragraph  
that one can negotiate or filter your way into enabling a pinhole; I  
see the utility. You made this clear during the NSIS discussion as well.

> And if the document is going to say that no future protocol is  
> going to
> use RAO, then please provide a viable alternative that will work  
> better.

DW: Use IPv6 RA :-)

-DWard

>
> Cheers
>
> Magnus Westerlund
>
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Färögatan 6                | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email protected]
> ----------------------------------------------------------------------
> _______________________________________________
> routing-discussion mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/routing-discussion