Subject: RE: RSVP Hello

From: "Martin, Christian" <[email-masked]>
Date: Mon, 27 Aug 2001 12:22:17 -0400

David,

Thanks for the reply.  Comments inline...

> 
> > Back to RSVP-TE, let us do something similar.  Again, we have two
> > RSVP-TE endpoints that we wish to build an LSP between.  During the
> > reservation setup step, we discover that we are not receiving RESV
> > or RESVERR messages back.  Hrm.  Where is the problem?  We can do
> > pings and traces, but that does not inform us whether or not there
> > is a nodal RSVP handling issue on one or more processing devices in
> > the path.  But what device?!  This is where I see a problem.
> 
> This is actually covered in the draft.  Admission control 
> errors, which
> in RFC 2205 cause the generation of ResvErr, in the RSVP-TE 
> draft cause
> the generation of PathErr.  See section 4.7.3 of the RSVP-TE draft.

A device (router) cannot send PathErr if it doesn't speak RSVP.  In 2205,
there is mention of Path messages passing through non-RSVP clouds.  For RSVP
flow reservations, this is fine, but for ERO/LRO's, this is not.  I would
think that the only response a router would take that isn't RSVP aware would
be to send an ICMP port unreachable message back to the source, as the UDP
port isn't awake.  I am trying to preemt this by knowing ahead of time that
a router is not listening to or processing RSVP messages.  There are
procedures for recongizing whether or not LRO is supported, but not whether
RSVP is supported.  Or am I missing something in the draft?

> 
> In the case of a failure that takes place after the LSP is 
> set up, RSVP
> Hello will detect the failure and appropriate PathErr/ResvErr messages
> should be sent to the endpoints of the LSP.  I don't know about GMPLS
> (where data- and control-planes are separate) but I would 
> assume that a
> similar mechanism exists there.

This is fine as it exists today.  I should also note that once a network has
built recervation state (and thus hello state), then everything is ok.  It
is the problems that occur while building the state that I am addressing.

-chris

> In other words, the ingress node will be told about the 
> failure.  It can
> then try again with different parameters or report the failure to
> management.
> 
> -- David
>

---

From: David Charlap <[email-masked]>
Date: Mon, 27 Aug 2001 12:34:43 -0400

"Martin, Christian" wrote:
> 
> A device (router) cannot send PathErr if it doesn't speak RSVP.  In
> 2205, there is mention of Path messages passing through non-RSVP
> clouds.

And this is made illegal in the RSVP-TE draft.  See sections 4.2.5 and
4.5.

If an RSVP router has a non-RSVP downstream neighbor, it must not send a
Path message with a label-request object.  Instead, it should send a
PathErr message.  Similarly, if a router receives a Path message with
label-request from a non-RSVP router, it should send back a PathErr
message.

The draft specifies the presence of a label-request object, because this
is the primary mechanism for differentiating an RSVP Path message from
an RSVP-TE Path message.  Within any reasonable kind of MPLS cloud, all
Path messages will be RSVP-TE and will have label-request objects.

-- David