The MPLS WG Archive

[David Charlap <David.Charlap@marconi.com>]

Curtis Villamizar wrote:
> David Charlap writes:
>> Adrian Farrel wrote:
>>
>>> According to RFC3209 what is the correct behavior of an upstream LSR when
>>> it receives a PathErr?Should it:
>>>- forward the message but retain Path and Resv state
>>
>>Yes
>>
>>> - forward the message and retain Path state but discard Resv state
>>> - forward the message and retain no state
>>> - something else.
>>> References would help.
>>
>> Unless a specific PathErr/ResvError's specification says otherwise, you
>> should forward error messages to the appropriate ingress/egress node(s).
>> The edge nodes should do all the real work.
>>
>> See RFC 2209 - message processing rule for RSVP.  Section 2.
>>    (snip)
> 
> But you may not want to rely on this behaviour (or implement it for
> that matter since it holds onto resources that just lead to a
> blackhole downstream) because some vendors believe that the
> microflow-RSVP behaviour above does not apply to RSVP-TE and many
> routers in the field discard forwarding state on RSVP-TE path-err,
> regardless of how many times a few people on this list cite the
> reference.

This can only blackhole traffic if the implementation is violating the 
RFC in other ways as well.  At the time these errors are generated, the 
Resv message has not yet arrived at the ingress node.  As such, the 
ingress node should not consider the LSP to be "up", and should not be 
trying to forward any trafrfic into it.  This holds true whether you 
allocate resources during Path processing (an optimization some vendors 
do) or during Resv processing (a strict interpretation of the RFCs).

If the consensus of this working group is to ignore the RFCs, then why 
bother even having them to begin with?

-- David