RE: TE Requirements Draft - ELSP

["Roberto Mameli (ERI)" <Roberto.Mameli@eri.ericsson.se>]

Hi Joel,

please see below.

> -----Original Message-----
> From: Joel M. Halpern [mailto:joel@stevecrocker.com]
> Sent: Tuesday, November 20, 2001 8:18 PM
> To: Roberto Mameli (ERI); TE WG
> Subject: RE: TE Requirements Draft - ELSP
> 
> 
> The CAC is not the problem.

Yes, I completely agree.

> The CSPF, and the source of the information for the CSPF, is the 
> problem.  Not only do you have to give the requirements to the CSPF 
> algorithm (a local process, or a central one, or ... but 
> anyway not what we 
> are discussing), but you also must include all N individual bandwidth 
> requirements in your request.

I don't understand why CSPF is the problem. I mean that including all the N individual bandwidth requirements in the LSP set up request does not represent a huge obstacle. In principle there are several approaches to do so. A possible one is based on the definition of a new Ctype for the Sender_Tspec and Flowspec objects in RSVP-TE, and is described in details in:
http://www.ietf.org/internet-drafts/draft-iovanna-rsvp-mpls-flowspec-00.txt
So, only a slight addition to the protocol, with minor impact and preserving backward compatibility. Why not?


> Therefore, what you have done is NOT signal one TE LSP, but rather to 
> signal N LSP with the requirement that they be routed, protected, and 
> re-routed together.  You got no effective scaling benefit 
> because all the 
> bookkeeping has to look at these as separate LSPs.

I do not agree. If you signal one LSP supporting N classes you have just one entry in each LSR forwarding table, one message for set up, one message for tear down and, in the case of RSVP, one refresh message every 30 seconds. If you signal N LSP you get N entries in the forwarding tables, N set up messages, N tear down messages and, in the case of RSVP, N refresh messages every 30 seconds. And what about IGP flooding? If a single LSP set up triggers a change in the network status and the corresponding flooding, maybe it is better to set up just one LSP instead of N. Thus some impact on the scalability exists. Maybe it is not dramatic, I agree! But I think that we should anyway consider it.

Again, I'm not saying that E-LSP is better than L-LSP. I'm not able to say it, since I am not a Service Provider. However I have no reasons to reject a priori E-LSP. If you give two options to a service provider, then let him choose without pushing towards a specific solution. Otherwise, don't give him two options... one is enough!

Best regards
Roberto