Subject: RE: Some Doubts

From: "Feng, Mark" <[email-masked]>
Date: Mon, 16 Jul 2001 09:46:34 -0700

To establish a LSP within a MPLS network, from the "first MPLS node on the
path"/ingress node to the "last MPLS node on the path"/egress node, the
ingress node should be the one to initiate the Path message.
 
Hope this helps.
 
Mark

-----Original Message-----
From: Adithya Bhat [mailto:[email-masked]]
Sent: Monday, July 16, 2001 2:26 AM
To: [email-masked]
Cc: Feng, Mark; [email-masked]
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:[email-masked] <mailto:[email-masked]> ]

Sent: Thursday, July 12, 2001 11:58 PM 
To: [email-masked] 
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