Subject: query : Label assignment

From: Neetu Gupta <[email-masked]>
Date: Thu, 28 Oct 1999 21:24:41 +0530

hi,
    we are implementing RSVP for creating LSPs with QoS resources. these
LSPs are dynamically created when there is a request.
    Please tell me, can we create LSPs for all existing routes initially
by LDP running simultaneously with RSVP that can provide Best   Effort
Services. If possible, how we'll do that, is it possible to divide the
supported label range into two, one for RSVP and other for LDP?
Neetu

---

From: "Makarand Kulkarni (98307005) " <[email-masked]>
Date: Fri, 29 Oct 1999 10:52:39 +0530 (IST)

> by LDP running simultaneously with RSVP that can provide Best   Effort

I feel that there should be no need of running RSVP and LDP 
simultaneously. The RSVP messages can then provide best effort services 
by not reserving anything along the path -- they will just be used for 
setting os path. Please correct me if this is not possible 

--Makarand

> supported label range into two, one for RSVP and other for LDP?
-------------------------------------------------------------------------------
Makarand G Kulkarni                  | Ph.No. (+91-22)-578-1017Ext.5601,7414
Department of Electrical Engineering |                               8498 
IIT - Bombay                         | URL : http://wowsites2.com/makarand
Powai, Bombay 400 076, India         | Email: [email-masked] 
-------------------------------------------------------------------------------
SPANN LAB: Direct Line: (+91-22)-579-0651
-------------------------------------------------------------------------------

---

From: "Navin kumar Agrawal" <[email-masked]>
Date: Fri, 29 Oct 1999 18:52:31 +0530

Hi Neetu,

See my comments below.

Neetu Gupta wrote:

> Services.

In my opinion there is no need to run MPLS-LDP along with MPLS-RSVP, you
can do this with MPLS-RSVP along. My idea in this regard is as stated below:

Generally speaking MPLS-RSVP is a request based protocol. That means the
trigger for setting up an LSP comes dynamically from an application. But
your
requirement is such that it  should be done as soon as the MPLS-RSVP
daemon program comes up and also should keep track of changes in the routing

table entries. This static requirement can be implemented in a seperate
task, say
the MPLS-RSVP daemon task itsefl spawns this task for creating LSP
corresponding to each network prefixes present in the routing table.

And as far as the best-effort service is concerned for LSPs, which I mostly
refer as Vanila LSPs, it can be created with ctype = COS for FLOWSPEC
and SENDER_TSPEC objects.

How does this sounds? Let me know.

> If possible, how we'll do that, is it possible to divide the

If you are making the MPLS module as the authorised place for the allocation

of labels...there shouldn't be any problem even if we have more than one
label distribution protocols running above it. Ideally speaking...No
partitioning
required.

Did I say anything wrong? Let me know if there is any.

Regards,
Navin

---

From: Rohit Chhapolia <[email-masked]>
Date: Fri, 29 Oct 1999 10:46:39 -0400

> can do this with MPLS-RSVP along. My idea in this regard is as stated below:

Though RSVP can be used the way described below for creating best effort
(and I assume, you also imply hop-by-hop routed LSPs), LDP is more
suitable for creating such LSPs. RSVP does not provide support for merging
labels which could be a desired feature here. However, whether one still needs
to run both on any link will depend on type of services one wants to provide
on such links.

> label distribution protocols running above it. Ideally speaking...No

To add further, if your label space management is done individually by each module
in different memory space, you would have to partition your label space. It would be
required due to implementation not by protocols.

Rohit

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

---

From: Neetu Gupta <[email-masked]>
Date: Sat, 30 Oct 1999 04:59:51 +0530

Navin
    Is there any other protocol that creates LSPs by  the procedure that is not
Hop-by-hop based?
Of all the mails i have received, it's being given, LDP is better that RSVP for
LSP creation, we should not use LDP simultaneously with RSVP, and RSVP is
dynamic and request based LSP creation protocol, and also, there is lot of
overhead in using RSVP for creating LSPs for all the existing routes.
So what is the recommended practise?
I'm confused.
Neetu

---

From: Tony Li <[email-masked]>
Date: Sat, 30 Oct 1999 14:37:20 -0700

>     Is there any other protocol that creates LSPs by  the procedure that is not

It would be singularly different to have a protocol that established state at every
node along a particular path without having communications follow the path.  Yes,
you could do other things, but they would be less efficient as they would
necessarily require communications with nodes that are _not_ involved in the LSP.

> So what is the recommended practise?

You've been the victim of Fear, Uncertainty and Doubt.

The first question to be asked is (as always): What problem are you solving?

If you are doing traffic engineering, you don't create an LSP per route.  That
would not be a scalable solution, regardless of the protocol.

There is no reason to use both RSVP and LDP, just as there is no reason to run both
OSPF and IS-IS.  Pick one tool for the job.  Both are mechanisms for establishing
LSPs.  Each has slightly different properties.  There is no "recommended" practice,
as the IETF is not in the business of recommending how you run your network.  It
simply provides technology.

The difference in overhead of the two protocols has, in practice, been sufficiently
low as to be irrelevant.  The real overhead for traffic engineering applications is
the path computation and has nothing to do with the signaling of the path.

I won't begin to speak to any application other than traffic engineering.

Regards,
Tony

p.s. My personal preference is, of course, for RSVP.  I'm slightly biased.  ;-)

---

From: "Peter Ashwood-Smith" <[email-masked]>
Date: Sat, 30 Oct 1999 21:28:14 -0400

> You've been the victim of Fear, Uncertainty and Doubt.

  I guess that makes me "Mr Doubt", that leaves "Mr Uncertainty"
and "Mr Fear" ... any takers? 

> simply provides technology.

  Perhaps but the ITU is in the buisness of recommending and they have recently
recommended CR-LDP over RSVP for traffic engineered IP over ATM in public networks.
 
> the path computation and has nothing to do with the signaling of the path.

  Ok, I REALLY disagree with this statement. My own experience and the experience of
my team (which has  30+ man years experience with connection oriented protocols)
is that the overhead IS the per hop processing, not the path computation. We have
found that computing thousands of paths per second is fairly easy with modern 
processors but that instantiating more than half that per second is hard to
do. On average a path setup may require up to a K of data be processed in both
directions at every hop, this data is packed such that it must be read a byte at a 
time so the overall hop by hop processing can be on the order of a million or so
instrcutions per LSP/hop. 

> p.s. My personal preference is, of course, for RSVP.  I'm slightly biased.  ;-)

  As am I, for CR-LDP, and the bias is considerably more than slight ;)

  Regards,

  Peter

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 31 Oct 1999 18:07:53 -0800

Peter,

> recommended CR-LDP over RSVP for traffic engineered IP over ATM in public networks.

ITU did not recommeded CR-LDP over RSVP simply because RSVP-TE was not even
presented on time as an alternative option. The fact that ITU SG13 looked at
CR-LDP was because that was the only option available for TE signalling at that
time at ITU. Since I see this "over RSVP" popping often I would suggest to
refrase this a little so it describes a bit more precise the "selection"
process.

R.