Subject: Re: BANDWIDTH RESERVATION - RE: Announcing draft-ietf-mpls-diff-ext-03.txt

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 01 Mar 2000 11:36:43 -0500

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

>Thanks,
>Curtis
_________________________________________________________________
Francois Le Faucheur   
Development Engineer, IOS Layer 3 Services 
Cisco Systems 
Office Phone:   	+33 4 92 96 75 64
Home Office Phone:     +33 4 92 94 00 78
Mobile :               +33 6 89 10 81 59
Vmail:                 +33 1 58 04 62 66
Fax:                   +33 4 92 96 79 08
Email:          	[email-masked]
_________________________________________________________________
Petra B - Les Lucioles - 291, rue Albert Caquot - 06560 Valbonne - France
_________________________________________________________________

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Mar 2000 16:00:01 -0500

In message <[email-masked]>, Francois Le Faucheur write
> Curtis,

Francois,

Thanks for the reply.  There is one thing I may not have been clear
about.

> with per-OA admission control achieves less efficient routing than Mode 2

The purpose is not to do per OA admission control.  From the
standpoint of admission, the reservation is the sum of the OA
reservations at a given holding-priority and the whole thing is either
accepted or rejected.  If accepted, some of the queue weights need to
be adjusted.  The per OA amounts are then used solely to adjust the
correct queue wights by the correct amount.

{ \begin{aside}
In my view of the world ATM CAC was a mistake worth not repeating.
Overbooking (MAM in Awduche-speak) allows a transient condition where
too much bandwidth may be temporarily accepted but later (not too much
later if you get it right) attempts to reoptimize (ie: using a good
adaptivity implementation, rather than the naive fixed timer approach)
will then move traffic away from the transient congestion.
\end{aside} }

You may also want to do strict CAC, but if so, the LSP would be
accepted or rejected based on the sum of the per-OA reservations.  In
either case this sum is what is subtracted from the advertised
available reservable bandwidth per priority.

> because of admission control)?

Yes.  See above.  You may have been thinking that we had some
intention to use the per OA reservations for CAC.  That was mistaken.
When a reservation arrives we can configure the router to steal queue
weight from best effort.  This just provides an accurate means to
determine where to apply the queue weight stolen from best effort.

Curtis