The MPLS WG Archive

[Francois Le Faucheur <flefauch@cisco.com>]

All,

At 08:04 28/11/2000 +0100, Daniel N. Bauer wrote:
>
>Maybe a solution is to extend the signaling and include optionally the
>BW requirements per OA for E-LSPs.
>

For information:
The question of whether it would be worth adding yet another option to the
spec to support per-OA bandwidth signalling (for admission control
purposes), has already been discussed when progressing the draft (see
thread "Re: BANDWIDTH RESERVATION - RE: Announcing").
Below is one message from that thread which should give you some background
as to why we elected to not include such extensions.
Hope that is useful.
Francois

>Delivered-To: flefauch@cisco.com
>X-Sender: flefauch@europe.cisco.com
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 
>Date: Wed, 01 Mar 2000 11:36:43 -0500
>To: curtis@avici.com
>From: Francois Le Faucheur <flefauch@cisco.com>
>Subject: Re: BANDWIDTH RESERVATION - RE: Announcing
>  draft-ietf-mpls-diff-ext-03.txt 
>Cc: Francois Le Faucheur <flefauch@cisco.com>,
>        Shahram Davari <Shahram_Davari@pmc-sierra.com>,
>        "'Juha Heinanen'" <jh@lohi.eng.telia.fi>, curtis@avici.com,
>        mpls@UU.NET, bsd@cisco.com, liwwu@europe.cisco.com,
>        pasi.vaananen@ntc.nokia.com, ram@nexabit.com,
>        Pierrick.Cheval@alcatel.fr
>Sender: flefauch@cisco.com
>
>Curtis,
>
>At 19:22 25/02/2000 -0500, Curtis Villamizar wrote:
>
>>You have a fine I-D and I do agree that L-LSPs can be used if
>>reservation per BA is desired.  It is just more efficient to use an
>>E-LSP if more than one BA can be accomodated given the limited EXP
>>bits and also given the requirements of the BAs wrt fast-reroute,
>>adaptivity, and resilience match.  In the interest of making that
>>improvement in efficience possible, I would prefer if you would add
>>per BA (or per PHB as the MAPs are now defined) bandwidth as an option
>>to the MAPs for E-LSPs.
>>
>>Please consider making this change to the I-D.
>>
>
>I am considering... but not convinced.
>
>We agree that if one wants to do per-OA Routing and per-OA admission
>Control, then this can be done using L-LSPs + bandwidth reservation as
>currently defined. Call this Mode 1.
>We also agree that if one  wants to do aggregate routing of Multiple-OAs
>and Aggregate Admission Control of Multiple-OAs, then this can be done
>using E-LSPs + bandwidth reservation as currently defined. CAll this Mode 2.
>
>The suggestion above is for extensions allowing aggregate routing/transport
>of multiple-OAs with per-OA admission control. Call this MOde 3. Firstly,
>such an extension would also require defining the procedures and error code
>for handling situations where the admission control for one OA is
>successful while the admission control for another OA is rejected. You
>woudl have to reject the E-LSP explaining which admission control failed.
>Secondly, that would mean that you cannot route one OA onto a Path which
>has capacity for it simply because it happens to travel on an E-LSP along
>another OA which has run out of capacity. In other words, multi-OA Routing
>with per-OA admission control achieves less efficient routing than Mode 2
>would.
>Is this not right?
>
>So, all in all, I still think:
>	- you can do pretty good and label-efficient with Mode 1 
>	- you can do the ideal per-OA thing with Mode 2. 
>	- Mode 3 does not have a strong application in between these 2.
>	- there are already quite a lot of options in our spec...
>
>Do you still see a strong application for Mode 3 which would justify
>extensions in the MAP but also extensions in all the error codes and
>procedures (today we rely on normal RSVP error handling to signal rejection
>because of admission control)?
>
>Opinions from others?
>
>Cheers
>
>Francois
>

>Regards,
>-Daniel
>