Subject: RE: Some Doubts

From: "Feng, Mark" <[email-masked]>
Date: Fri, 13 Jul 2001 10:30:46 -0700

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]]
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

---

From: Adithya Bhat <[email-masked]>
Date: Mon, 16 Jul 2001 14:55:37 +0530

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-----

Sent: Thursday, July 12, 2001
11:58 PM

To: [email-masked]

Subject: Some Doubts

Hi *,

"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."

Thanks in advance

Adithya

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Mon, 16 Jul 2001 14:00:30 -0400

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

Regards
Madhubabu
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Adithya
Bhat
  Sent: Monday, July 16, 2001 5: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]]
      Sent: Thursday, July 12, 2001 11:58 PM
      To: [email-masked]
      Subject: Some Doubts

      Hi *,

              "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."

      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 ?

      Thanks in advance

      Adithya

---

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

> Is it possible to have MPLS aware nodes but not aware of RSVP-TE???

Yes.  It is possible that some vendor's implementation may support LDP
or CR-LDP but not RSVP-TE.

It is also possible that the RSVP-TE protocol may be disabled on a
switch.

-- David