The MPLS WG Archive

[Adrian Farrel <AF@dataconnection.com>]

>> >>Because the Notify message is sent instead of a regular PathErr
>> >>message, a node that receives the Notify but does not support it
>> >>will not get any error indication from RSVP signalling at all!
>> >
>> >I think it's worth pointing out that Adrian's version differs
>> >from the most recent draft, which says "The Notify message does
>> >not replace existing error messages. "  I think any attempt to
>> >replace base RSVP messages with a notify would be misguided.
>> >I don't know if this is what Adrian meant to
>> >imply.  (Although this is one reading of the his text.)
>>
>>Not my intention (except with consent of the LSRs involved).
>>see my response to Markus.
>
>The exception is surprising.  Why would you want to remove 
>base (rfc2205 specified) error messages?

If there is no value in sending them.

In some circumstances, the Notify obsoletes the PathErr.

You would send one PathErr for each failed LSP and process it hop-by-hop.
This is excessive, especially when a large number of LSPs fail.

If a multi-LSP Notify flows it can replace the need for the PathErr.

If the Notify is targeted at a non-ingress repair point, we would have to
change the rules for PathErr processing to achieve the same function (o/w
the PathErr would be forwarded all the way to the ingress where it might
produce a different effect).

My suggestion is that the node requesting Notify is able to say whether it
wants the node that generates the Notify to use PathErr or not.

Adrian