Subject: RE: Typo in rsvp-lsp-tunnels draft ??

From: K Arvind <[email-masked]>
Date: Sat, 7 Aug 1999 12:25:46 -0400

Rohit,

>If the bandwidth reservation is done in the forward path (i.e., when
>the PATH message is received), it should be PathErr message. Though
>RSVP specifies reservation should be done when RESV message is received,
>while setting up LSPs it would be more useful to do so during PATH
>processing like CRLDP or ATM signaling. I think rsvp-tunnel draft should
>explicitly mention so.

   Wouldn't setting up reservations when processing Path messages be a 
major deviation from RFC2205 RSVP? One of the major benefits of the TE-RSVP 
approach is that it allows us to reuse and adapt exisitng RSVP 
implementations. Wouldn't such a deviation significantly impact reuse of 
existing RSVP implementations? Wouldn't it cause interoperabiliy problems?

   It is intuitively more appealing to set up reservations on the way down 
(when PATH messages are received) and using Resv messages just as 
confirmations that tunnel setup is complete. If we were to come up with a 
signaling protocol for MPLS from scratch (e.g., CR-LDP), this would be a 
good approach to take. However, are there really enough advantages to 
redefining RSVP to make reservations on the way down? If so, do these 
advantages outweigh the disadvantages pointed out above?

  I think the total amount of processing work will roughly be the same 
whether reservations are setup on the way down or on the way back. In one 
case (RFC 2205), Path messages do little work (they essentially set up the 
reverse path) while in the other case Resv messages do little work (they 
essentially serve as acks).

   If you consider reservation failure scenarios, the RFC 2205 approach 
would result in a lot of "wasted effort" if a reservation failure occurs 
close to the head end of the tunnel. Reservations already setup along the 
entire path up to the tail end have to be torn down in this case. On the 
other hand, the other approach (reserve when processing Path messages) 
would result in a lot of wasted effort, if a reservation failure occurs 
close to the tail end of the tunnel. In this case, reservations set up 
along the entire path back to the head end have to be torn down. Of course, 
the response time when there is a reservation failure would be worse for 
the RFC 2205 approach, since it will always be equal to at least the 
end-to-end delay.

Regards,
Arvind.

K. Arvind, Ph.D.
TENOR Networks, Inc.
50, Nagog Park, Acton, MA 01720
W: 978-264-4900 x124
F: 978-264-0671
E: mailto:[email-masked]
U: http://www.tenornetworks.com

-----Original Message-----
From:	Rohit Chhapolia [SMTP:[email-masked]]
Sent:	Saturday, August 07, 1999 10:12 AM
To:	Ram Krishnan
Cc:	[email-masked]
Subject:	Re: Typo in rsvp-lsp-tunnels draft ??

Ram,

If the bandwidth reservation is done in the forward path (i.e., when
the PATH message is received), it should be PathErr message. Though
RSVP specifies reservation should be done when RESV message is received,
while setting up LSPs it would be more useful to do so during PATH
processing like CRLDP or ATM signaling. I think rsvp-tunnel draft should
explicitly mention so.

Rohit

Ram Krishnan wrote:
>
> To authors of the rsvp-lsp-tunnel draft,
>
> This may have already been pointed out before. On page 39, in section
> 4.7,
> 3rd paragraph,
> "If the requested bandwidth is not available, a PathErr message is
> returned ..."
>
> Shouldn't it be a ResvErr message sent to downstream nodes towards the
> receiver ?
>
> Regards,
> Ram Krishnan

--
Rohit Chhapolia
Ficon Technology, Inc.
mailto:[email-masked]
http://www.ficon-tech.com

---

From: Eric Gray <[email-masked]>
Date: Sun, 08 Aug 1999 12:09:17 -0400

Arvind,

	Your analysis raises good points.

	The intuition I have however is that the cumulative
work of the system is less if a reservation that will fail,
fails as early in the process as possible.  This would mean
at least attempting to reserve resources in processing PATH
messages.  The cumulative work of the system, I believe, is
more influential in determining scalability.

	I know that RFC 2205 does require reservation of
resources in PATH processing; does it explicitly prohibit
it?  I would think it would be hard to tell - externally -
that an implementation is doing this, and I suspect that 
this makes interoperability of the two approaches a non-
issue as well.

---

From: Eric Gray <[email-masked]>
Date: Sun, 08 Aug 1999 12:27:23 -0400

>         I know that RFC 2205 does require reservation of

Whoops!  Meant to say "does NOT require"...

---

From: Rohit Chhapolia <[email-masked]>
Date: Mon, 09 Aug 1999 09:35:38 -0400

Arvind,

> > existing RSVP implementations? Wouldn't it cause interoperabiliy problems?

As Eric wrote, it should not be externally visible if an implementation is doing
resource reservation in PATH or RESV processing.

> > advantages outweigh the disadvantages pointed out above?

It is really not necessary to force implementations to do reservations in 
forward or backward path. But, as you agree, it is a better approach to reserve
resources in PATH processing. I think, it is really a implementor's choice whether
they want to take more pains to do something better.

> > essentially serve as acks).

In the other case, RESV messages do another useful work of giving label
to upstream node.

> > the RFC 2205 approach, since it will always be equal to at least the

I agree and this is a good reason for reserving resources in PATH processing.

Rohit

---

From: "Navin kumar Agrawal" <[email-masked]>
Date: Mon, 09 Aug 1999 19:30:36 +0530

Hi All,

See my comments below.

Navin

> they want to take more pains to do something better.

You have come to the conclusion very fast. Infact, If you look at the
complete implementation of provisioning QoS using RSVP, you would
realize that either method of implementations (i.e. doing reservation during
Path message traversal or during Resv message traversal) would be equally
costly/complex. Let me prove it this way.

You want to do resource reservation for a particular session. And suppose
that you want to do this during the traversal of the Path message itself. This
would involve the sender node to have a QoS requirment which can be accepted
by each of the transit node in the network. There are two ways a  sender node can go
ahead.

    1. Make some wise guess
    2. Maintain some kind of database about the information of the resource
    availability at different nodes in the network (this method recalls me of PNNI).

    As far as the first approach is concerned, this is basically a trial & error
approach, and could be very costly. And I guess, I need not to explain the
complexity involved in the second approach.

Please get back to me in case of some disagreement.