The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

Hi Curtis,

>> Building on the Summary Refresh construct in
>> draft-ietf-rsvp-refresh-reduction, I am proposing a solution 
>> where a single Notify carries information about more than one
>> failed LSP.  The restrictions are
>> - all LSPs reported on one Notify must be for the same Notify 
>>   target
>> - the same error spec must apply to all LSPs reported on the 
>> same Notify
>
>Sounds worthwhile.

Thanks.  I'll take that as "Sounds worthwhile so long as Notify isn't killed
off." :-)

>>    The Notify message is sent addressed to the target node 
>>    without the router alert option (see 5.1.1).  This means
>>    that at transit nodes the IP packet may be forwarded by 
>>    IP without being passed to the RSVP protocol code.  If a
>>    Notify is passed to the RSVP protocol code on a node 
>>    which is not the destination of the Notify message, that
>>    node MUST forward the message, unmodified, towards the 
>>    target.
>>    If it is known or suspected that the transit nodes will 
>>    unnecessarily intercept Notify messages, they MAY be sent
>>    encapsulated in a second IP header.
>
>It was pointed out earlier that routers can capture and examine RSVP
>regardless of whether router alert is set.  [Maybe good advice would
>be "if it hurts, don't do that".]

can != do

It would be bad to assume that routers do not intercept even when
router alert is not set.  It doesn't seem unreasonable to look for
optimizations in the case where the router alert and dst address
are interpreted correctly.

Personally I am not a fan of double IP encapsulation and would 
gladly see it left out, but it was in the original text and I am
far too polite to remove it myself.  I would be happy with text 
that said that the Notify was intended to be routed direct to the
target and not examined by the RSVP protocol stack at any other
LSR (i.e. the penultimate paragraph).

Adrian