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

Roland -

On Oct 21, 2008, at 3:35 AM, Roland Bless wrote:

> Hi Magnus,
>
> Magnus Westerlund wrote:
>> 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?
>
> Yes, the behavior should be: simply forward the packet in case
> the router does not understand/intercept packets with this RAO value.
> Otherwise an efficient interception as we need it in NSIS is
> not possible.
> If the router is the destination of the packet and it doesn't
> understand the RAO, it probably could drop the packet.
>

DW: The RSVP spec doesn't state this clearly thus the confusion.



>> packets. Then adding filtering behavior to prevent overloading the  
>> slow
>> path and this would work better than the alternative of not using  
>> RAO.
>
> Yep.
>
>> 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.
>>
>> 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.
>
> I strongly agree with Magnus here.
>  Roland
>