The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <40A00965.7020704@marconi.com>, David Charlap writes:
> Adrian Farrel wrote:
> > 
> > According to RFC3209 what is the correct behavior of an upstream LSR when i
> t 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.
> 
> PathError:
> 
> 	...
> 
> 	PERR MESSAGE ARRIVES
> 
> 	o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
> 	  matches the corresponding objects in the message.  If no
> 	  matching PSB is found, drop the PERR and return.
> 
> 	o If the previous hop address in the PSB is the local API,
> 	  make an error upcall to the application:
> 	    ...
> 	  Otherwise, send a copy of the PERR message to the PHOP IP
> 	  address.
> 
> 	o Drop the PERR message and return
> 
> ResvError:
> 
> 	...
> 
> 	RERR MESSAGE ARRIVES
> 
> 	A RERR message arrives through the (real) incoming interface
> 	In_If.
> 
> 	o If there is no path state for SESSION, drop the RERR
> 	  message and return.
> 
> 	o If the Error Code = 01 (Admission COntrol failure), do
> 	  special processing as follows:
> 	    ...
> 	  (description of blockade-state algorithm snipped)
> 
> 	o Execute the following for each RSB for this session whose
> 	  OI differs from In_If and whose Filter_spec_list has at
> 	  least one filter spec in common with the FILTER_SPEC* in
> 	  the RERR message.  For WF style, empty FILTER_SPEC*
> 	  structures are assumed to match.
> 
> 	  1. If Error_Code = 01 ...
> 	     (special handling for blockade procedure snipped)
> 
> 	  2. If NHOP in the RSB is the local API, then:
> 
> 	     - If the FLOWSPEC in the RERR message is strictly
> 	       greater than the RSB Flowspec, then turn on the
> 	       NotGuilty flag in the ERROR_SPEC.
> 
> 	     - Deliver an error upcall to application:
> 	         ...
> 	       and continue with the next RSB
> 
> 	  3. If the style has wildcard sender selection...
> 	     (snip - WF is not applicable to MPLS)
> 
> 	  4. Create a new RERR message containing the error flow
> 	     descriptor and send to the NHOP address specified by
> 	     the RSB.  Include SC.Out if the style has wildcard
> 	     sender selection.
> 
> 	  5. Continue with the next RSB
> 
> 	o Drop the RERR message and return.
> 
> -- David


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.

Curtis