Subject: RE: Last calls for RSVP Extensions drafts

From: K Arvind <[email-masked]>
Date: Sat, 18 Sep 1999 16:31:20 -0400

A few weeks ago there was some discussion on this mailing list regarding 
when resources ought to be reserved during LSP setup (for LSP's that 
require resource reservation): should resources be reserved during Path 
message processing, during Resv message processing, or does it matter at 
all when this is done?

Given that the rsvp-lsp-tunnel draft is based on RSVP, it is reasonable to 
assume that the draft implicitly prescribes the same rules of procedure 
that RSVP uses, i.e., reserve resources during Resv message processing. 
However, the reservation procedures used by RSVP are somewhat 
counter-intuitive when applied to the setup of LSP tunnels, since tunnel 
setup is initiated by the head end. All the information needed to make 
reservations is available during Path message processing, and one can 
therefore argue that it may be more "natural" to reserve resources during 
Path message processing. In fact, both approaches seem to be in use 
currently, which raises the possibility of potential interoperability 
issues.

I think the lsp-tunnel draft should provide some clarification on this 
ambiguity. It should either recommend exactly one of these two approaches, 
or specify how interoperability issues (if any) between implementations 
that use different approaches can be resolved.
If we can conclude with certainty that there can be no interoperability 
issues between the two approaches (as some postings have hinted), it would 
be helpful if the draft stated so.

Thank you..

Regards,
Arvind

PS: An unrelated piece of feedback: There is a typo in the penultimate 
sentence of Section 4.2.2 of draft-ietf-mpls-rsvp-lsp-tunnel-03.txt. This 
sentence should read as follows: "This same message should be sent, if a 
router receives a LABEL_REQUEST object in a message from a non-RSVP capable 
router."

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:	Vijay Srinivasan [SMTP:[email-masked]]
Sent:	Tuesday, September 14, 1999 9:59 AM
To:	[email-masked]
Subject:	Last calls for RSVP Extensions drafts

This e-mail announces the beginning of the last calls for
draft-ietf-mpls-rsvp-lsp-tunnel-03.txt and
draft-awduche-mpls-rsvp-tunnel-applicability-01.txt.

Please send your comments to the list.  The last call for these drafts
will end 5 pm US EDT, Monday, September 20.

- Vijay

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Sat, 18 Sep 1999 22:25:20 -0400

> assume that the draft implicitly prescribes the same rules of procedure
.......

  The following applies equally to CR-LDP and (god forbid) RSVP-tunnels.

  It is not an issue that must be standardized. However it makes more
sense for an
implementation to do a sort of two phased reservation internally. One on
the forward going message which simply sets aside the resources and a
more
permanent one in the reverse direction.

  The reasons for this are two fold:

      a) You may not succeed in getting resources all the way down 
the path and do not want to cause any kind of bandwidth update
until you are sure you really have a path up. Most implementations will
have some kind of threshold crossing trigger for floods and processing
in this two step manner prevents you from wasting a flood.

      b) When dealing with preemption a.k.a bumping, it makes more sense
to start a bumping mechanism only after the receipt of the reverse
flowing
messages so that you will avoid preempting only to discover later that
you cannot get resources upstream and have unnecessarily preempted
other LSPs.

   Cheers,

   Peter

---

From: "Navin kumar Agrawal" <[email-masked]>
Date: Mon, 20 Sep 1999 20:32:40 +0530

Hi Arvind,

See my comments below.

> that RSVP uses, i.e., reserve resources during Resv message processing.

Undoubtedly correct.

> setup is initiated by the head end.

:-(

> All the information needed to make
> reservations is available during Path message processing,

The rsvp-tunnel draft has only specified the mechanism for setting up
LSP using RSVP as a signalling protocol. There is no change suggested
by this draft in the context of resource reservation mechanism. Hence,
I don't agree with the above statement.

In this comment, I have assumed that you are agreeing with the
resource reservation mechanism of classical RSVP (2205), which
is receiver oriented.

Hence, there is no need to provide any info about the interoperability
between sender and receiver oriented reservation mechanism in the
rsvp-tunnel-draft.

Regards,
Navin

> and one can

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Tue, 21 Sep 1999 22:39:37 -0400

Cheng Yin Lee wrote:
> 
> "Ashwood-Smith, Peter (P.J.) [EXCHANGE:CAR:CF57-I:BNR]" wrote:
> 
>  Is this flood mechanism use to inform ingress LSRs the current amount
> of link bandwidth available in internal LSRs? 

  Yes, LSRs that are sourcing LSPs (we are calling them LER's or
label edge routers) need to know the state of bandwidth availability
on LSRs they wish to establish LSPs over. Of course this is only if
they want to dynamically compute the routes. If you only care about
a statically routed LSP then no OSPF or IS-IS modifications are 
required.

> If so, does this mean that
> only ingress LSRs need to know this information, if LSPs are setup from
> ingress LSRs only?

  Technically yes but in reality, the internal LSRs have to propogate
the
information anyway so they may as well store it. Also, internal LSRs
will
probably participate in other forms of traffic engineering like various
forms of repair or splicing so having bandwidth information available is
necessary.

  Cheers,

  Peter Ashwood-Smith