Subject: RE: Some Doubts

From: "Feng, Mark" <[email-masked]>
Date: Mon, 16 Jul 2001 11:33:55 -0700

The bottom line is that, the label request must be understood and processed
by each node along the LSP path. You could have nodes along the way that are
not RSVP-TE,  but the neighboring nodes has to do RSVP/LDP interworking. As
far as I know, there is no RFC/draft to address this. So, it is not possible
right now.
 
Mark

-----Original Message-----
From: Madhu Babu Brahmanapally [mailto:[email-masked]]
Sent: Monday, July 16, 2001 11:01 AM
To: [email-masked]; [email-masked]
Cc: 'Feng, Mark'; [email-masked]
Subject: RE: Some Doubts

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] <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: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Mon, 16 Jul 2001 14:51:00 -0400

Hi Feng,All,
When there are two possible solutions like CR-LDP and RSVP-TE, there should
be some IWF (might be in form of RFC ) between these as IMO both are going
to stay for ever.

Regards
Madhubabu
  -----Original Message-----
  From: Feng, Mark [mailto:[email-masked]]
  Sent: Monday, July 16, 2001 2:34 PM
  To: 'Madhu Babu Brahmanapally'; [email-masked]
  Subject: RE: Some Doubts

  The bottom line is that, the label request must be understood and
processed by each node along the LSP path. You could have nodes along the
way that are not RSVP-TE,  but the neighboring nodes has to do RSVP/LDP
interworking. As far as I know, there is no RFC/draft to address this. So,
it is not possible right now.

  Mark
    -----Original Message-----
    From: Madhu Babu Brahmanapally [mailto:[email-masked]]
    Sent: Monday, July 16, 2001 11:01 AM
    To: [email-masked]; [email-masked]
    Cc: 'Feng, Mark'; [email-masked]
    Subject: RE: Some Doubts

    HI All,

    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,
         message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6
and

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

          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: abhay <[email-masked]>
Date: Tue, 17 Jul 2001 09:46:09 +0530

Madhu,

      IMHO ,CR-LDP has a lot of extensions and drafts.

      RSVP-TE too..but this is kind of more stable in terms of changes and extensions.

      In a perspective vendors generally prefer to play with RSVP rather than CR-LDP

      Although some have CR-LDP implemented and interoperated with other vendors..

      Hope both stay and healthy competition gives rise to better working protocols..

      Regards,

      Abhay

Madhu Babu Brahmanapally wrote:

>  Hi Feng,All,When there are two possible solutions like CR-LDP and
> RSVP-TE, there should be some IWF (might be in form of RFC ) between
> these as IMO both are going to stay for ever.RegardsMadhubabu
>
>      The bottom line is that, the label request must be
>      understood and processed by each node along the LSP path.
>      You could have nodes along the way that are not RSVP-TE,
>      but the neighboring nodes has to do RSVP/LDP interworking.
>      As far as I know, there is no RFC/draft to address this. So,
>      it is not possible right now.Mark
>
>           HI All,Is it possible to have MPLS aware nodes but
>           not aware of RSVP-TE???RegardsMadhubabu
>
>                From: [email-masked]
>                [mailto:[email-masked]]On Behalf Of
>                Adithya Bhat
>                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?
>               > 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
>               > 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
>               > 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
>               >
>               >      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
>               >      3. What is the meaning of
>               >      "MPLS being negotiated, but
>               >      a non-RSVP capable router
>               >      stands in
>               >         the path."
>               >

---

From: Rajesh P Jain <[email-masked]>
Date: Tue, 17 Jul 2001 10:58:29 +0530

"Hi",
                        With respect to the discussion, I would like to
ask the following question.

In the diagram below, Let us consider that MPLS domain is from R3 to R7

Sender---R1---R2---R3---R4---R5---R6---R7---R8---Receiver

                In the routers R3 to R7, RSVP-TE is supported in the
MPLS domain. In the routers R1,R2 and R8, RSVP is suppported but not
MPLS.

                Now, The Sender sends a Path message towards the
receiver along the path R1 to R8.

                Will the router R3 (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.  - Section 2.2
- Operation od LSP tunnel in the Draft of RSVP extension for LSP tunnel)
insert the LABEL Request Object????

                Is it possible to establish the LSP tunnel in the MPLS
domain (R3 to R7) or should all the nodes (i.e R1, R2 and R8 also) along
the path from Sender to Receiver support MPLS ??

TIA
        Rajesh P Jain

abhay wrote:

>>      As far as I know, there is no RFC/draft to address this.
>>      So, it is not possible right now.Mark
>>
>>           HI All,Is it possible to have MPLS aware nodes
>>           but not aware of RSVP-TE???RegardsMadhubabu
>>
>>                > in such manner. For example, if the
>>                > ingress receives the Resv, how does
>>                > it know how far the LSP has been
>>                > 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
>>                > 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
>>                >
>>                >              "RSVP is designed
>>                >      to cope gracefully with
>>                >         neighbor that is known
>>                >      to not be RSVP capable, the
>>                >      router MUST NOT
>>                >         advertise the
>>                >      error code "Routing
>>                >      problem" and the error
>>                >      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 ?
>>                >

---

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

> receiver along the path R1 to R8.

R8 will reject the Path message, because it will include a LABEL_REQUEST
object, which a non-MPLS router will not be able to process.

It will probably also reject the SESSION object, since a non-MPLS router
won't understand the MPLS-specific C-Type of LSP_TUNNEL_IPv4

> Path message with a session type of LSP_TUNNEL_IPv4 or
> LSP_TUNNEL_IPv6 and inserts a LABEL_REQUEST object into the Path
> message.  - Section 2.2 - Operation od LSP tunnel in the Draft of
> RSVP extension for LSP tunnel) insert the LABEL Request Object????
> 
>                 Is it possible to establish the LSP tunnel in the
> MPLS domain (R3 to R7) or should all the nodes (i.e R1, R2 and R8
> also) along the path from Sender to Receiver support MPLS ??

Sender and receiver, as far as RSVP-TE are concerned, refer to the
endpoints of the LSP.  Sender will be R3, and receiver will be R7, since
that is the extent of MPLS.  Any attempt to signal the LSP beyond the
edge of the MPLS cloud will fail.

-- David