Subject: Query about handling Non RSVP neighbours in RSVP-TE

From: Gaitonde Anandprasanna <[email-masked]>
Date: Sat, 2 Dec 2000 21:47:28 +0530 (IST)

I am eager to know the following as it was not clear to me from the draft.
 
This is one of the paragrph from the draft 07.txt

 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."  This same message SHOULD be sent, if a router receives a
   LABEL_REQUEST object in a message from a non-RSVP capable router. See
   [1] for a description of how a downstream router can determine the
   presence of non-RSVP routers.   

Does it mean that if we find a non RSVP hop in between we should stop
propogating Path mesages forward or does it mean that when we forward the
path message it should not contain Label Request Object. 

If the latter is the correct option, then how can we acheive a proper
setting up of an LSP. Because if we dont put Label Request Object in Path
message there wont be any Label Object in Resv Message and if this
haapens the we have failed to distribute labels to all the nodes along the
path.

So i think the first option is the correct one ??
Please let me know if i am wrong....

Thanx in advance

Pras

---

From: David Charlap <[email-masked]>
Date: Mon, 04 Dec 2000 11:12:13 -0500

Gaitonde Anandprasanna wrote:
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    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."  This same message SHOULD be sent, if a router 
>    receives a LABEL_REQUEST object in a message from a non-RSVP
>    capable router. See [1] for a description of how a downstream
>    router can determine the presence of non-RSVP routers.

What's not clear here?  Non-RSVP routers are illegal in an RSVP-TE
cloud.  If a Path message should passthrough one, path setup is aborted
and a PathErr is sent.

> propogating Path mesages forward or does it mean that when we forward
> the path message it should not contain Label Request Object.

It means you do not propagate the message.  You generate a PathErr
message.  Hopefully, the ingress router will then choose an alternate
route that avoids the non-RSVP router.

The deal about LABEL_REQUEST is not intended as a part of label
distribution.  It is intended so that non-TE RSVP may continue to
operate through the non-RSVP router (which is specified as part of RFC
2205).

-- David