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

From: K Arvind <[email-masked]>
Date: Mon, 9 Aug 1999 11:49:37 -0400

Eric,

     Thanks for your comments. I think we agree that in normal (successful 
reservation) scenarios there won't be any significant difference between 
the two approaches.

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

      During failure scenarios, the cumulative work will be smaller because 
path messages do not have to traverse the
      entire route of the tunnel before a tunnel setup request is rejected. 
However, would the savings in
      cumulative work be really significant, and would it be really 
influential in determining scalability?
      (1) In traffic engineering applications, constraint-based routing 
(see draft-ietf-mpls-traffic-eng-00.txt) is likely to minimize the
           possibility of reservation failures.
      (2) Saving, if any, become smaller and smaller as the failure point 
approaches the tail end of the tunnel. The only savings
           consist of the work required to propagate Path messages.
      (3) Path messages do little more than setting up the reverse path.
      (4) When we consider label allocation failures also, any savings in 
work is lost, because label allocation is necessarily
          done on the way back to the head end (downstream-on-demand)

>	I know that RFC 2205 does [not] require reservation of
>resources in PATH processing; does it explicitly prohibit
      >it?

      It is not the case that RFC2205 just does not require reservation in 
PATH processing. Isn't it true that it does not even consider this 
possibility, given its IntServ orientation? RSVP assumes receiver-initiated 
reservations, and this assumption appears to be built into its 
specifications.  RFC2209 (RSVP V1 Message Processing Rules), which is 
intended to clarify the RSVP protocol specification in RFC2205 clearly 
describes the role of Path and Resv messages and how they should be 
processed.  Many public domain and commercial implementations of RSVP are 
based on RFC2209. Requiring reservations to be set up during Path message 
processing would interfere with the reuse of these off-the-shelf 
implementations.

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

   I am not sure. Without carefully considering all possibilities, it would 
not be safe to say that there won't be any interoperability problems 
between two implementations that both don't conform to RFC2209. If it is 
true that there are no interoperability issues, then the TE-RSVP draft must 
clearly say so.

   Again, I agree that making reservations during Path message processing 
is intuitively appealing and could result in some work savings. But that is 
not how RSVP as described in RFC2205 and RFC2209 (and on which TE-RSVPis 
based) works. Also, whether the savings are significant enough to make a 
significant deviation from RSVP is debatable IMHO. If an implementation 
that deviates from RFC2209 by making reservations during Path message 
processing would still be considered conformant to TE-RSVP, then the 
TE-RSVP draft must explicitly state so. Any potential interoperability 
problems must be identified and sorted out before such a change is made to 
the draft. In any case, the TE-RSVP draft should explicitly state when 
reservations are made, to eliminate any confusion.

  Thank you.

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:	Eric Gray [SMTP:[email-masked]]
Sent:	Sunday, August 08, 1999 12:09 PM
To:	[email-masked]
Cc:	'Rohit Chhapolia'; [email-masked]'; [email-masked]'
Subject:	Re: Typo in rsvp-lsp-tunnels draft ??

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.

You wrote:
>
> 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 << File: ewgray.vcf >>