The MPLS WG Archive

[abhay <abhay@multitech.co.in>]

Hello Madhubabu,

                Yes,with CR-LDP.

                Originally CR-LDP is meant for Label Distribution and has optional extensions

                for T.E Features which requires a resource management and allocator in conjunction.

                With RSVP we have a resource management..but it has been extended to help in the

                establishment of LSP tunnels..

                Regards,

                Abhay

"Jiang, Donghua (Donghua)" wrote:

 Madhubabu,Not, unless you prefer CR-LDP.Regards,Jane D. Jiang

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com]
Sent: Monday, July 16, 2001 11:01 AM
To: adithya@sasken.com; mpls@UU.NET
Cc: 'Feng, Mark'; sridhar@samsung.co.kr
Subject: RE: Some Doubts
 

HI All,Is it possible to have MPLS aware nodes but not aware of RSVP-TE???RegardsMadhubabu 

-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of Adithya Bhat
Sent: Monday, July 16, 2001 5:26 AM
To: mpls@UU.NET
Cc: Feng, Mark; sridhar@samsung.co.kr
Subject: Re: Some Doubts
 

Thanks for the reply,
In the same draft Section  2.2 say:-

 "To create an LSP tunnel, the first MPLS node on the path -- that is,
   the sender node with respect to the path -- creates an RSVP Path
   message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 and
   inserts a LABEL_REQUEST object into the Path message."

If each node along the way must support RSVT-TE/Label Request, Then what is the meaning of "the first MPLS node on the path " in the above sentence?
Does it not mean that some nodes  along the path are non mpls ??

Thanks,

Adithya
 
 

"Feng, Mark" wrote:

The intention is to establish a LSP from the ingress to the egress. I don't think it is appropriate for a transit node to terminate the request in such manner. For example, if the ingress receives the Resv, how does it know how far the LSP has been established?On the other hand, when the ingress node receives the PathErr, it knows what the problem is. It could decide to try the transit node as the egress node, though I don't know why it would want to do so.I guess you are right that in MPLS, each node along the way must support RSVT-TE/Label Request. If one of the nodes along the path cannot process the Label Request, that means the connection cannot be established end-to-end. As a result, we don't have a label-switched-path."MPLS being negotiated, but a non-RSVP capable router stands in the path."  means just that, there is a non-RSVP capable router on the intended path.Hope this helps.Mark

-----Original Message-----
From: Adithya Bhat [mailto:adithya@sasken.com]
Sent: Thursday, July 12, 2001 11:58 PM
To: mpls@UU.NET
Subject: Some Doubts

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