Subject: Some Doubts

From: Adithya Bhat <[email-masked]>
Date: Fri, 13 Jul 2001 12:27:57 +0530

Hi *,

In draft-ietf-mpls-rsvp-lsp-tunnel-08.txt Section 4.2.5 says

"RSVP is designed to cope
gracefully with non-RSVP routers anywhere

between senders and receivers. However, obviously, non-RSVP
routers

cannot convey labels via RSVP. This means that if a router
has a

neighbor that is known to not be RSVP capable, the router
MUST NOT

advertise the LABEL_REQUEST object when sending messages
that pass

through the non-RSVP routers.  The router SHOULD
send a PathErr back

to the sender, with the error code "Routing problem" and
the error

value "MPLS being negotiated, but a non-RSVP capable router
stands in

the path."

1. Why should a PathErr be  sent back to the sender ? Will the
current router not be a egress router, and hence should send a label binding
back.

2.  If the above is not true does it mean that all the routers
(from the sender  to the reciever ) should be  rsvp-te capable
( should support labels)  routers ?

3. What is the meaning of "MPLS being negotiated, but a non-RSVP
capable router stands in

the path."

Please throw some light on this,

Thanks in advance

Adithya

---

From: David Charlap <[email-masked]>
Date: Tue, 17 Jul 2001 14:41:28 -0400

Adithya Bhat wrote:
>    "RSVP is designed to cope gracefully with non-RSVP routers
>    anywhere between senders and receivers. However, obviously,
>    non-RSVP routers cannot convey labels via RSVP. This means
>    that if a router has a neighbor that is known to not be RSVP
>    capable, the router MUST NOT advertise the LABEL_REQUEST
>    object when sending messages that pass through the non-RSVP
>    routers.  The router SHOULD send a PathErr back to the sender,
>    with the error code "Routing problem" and the error value
>    "MPLS being negotiated, but a non-RSVP capable router stands
>    in the path."
> 
> current router not be a egress router, and hence should send a
> label binding back.

This is RSVP-TE, not LDP.  The egress router for an LSP is the router
specified in the SESSION object, and no other.  RSVP-TE signaled LSPs
can only terminate on the router specified by the SESSION object.  If
the LSP can not be established to that router, then it is an error
condition and the ingress router must be notified (via a PathErr object)

> 2.  If the above is not true does it mean that all the routers (from
> the sender  to the reciever ) should be  rsvp-te capable ( should
> support labels)  routers ?

Yes.  All the routers along the path from ingress to egress must support
RSVP-TE.

> capable router stands in the path."

Just what it says.  There's a router along the path from ingress to
egress that does not support RSVP-TE.

If an explicit route object is used, the ingress must generate a
different ERO that avoids the non-RSVP-TE router.  If ERO is not used,
then the LSP won't be able to come up unless the routing table changes
sufficiently so that the non-RSVP-TE router won't be used by the LSP.

-- David