RE: clarifications on MAR

["Ash, Gerald R (Jerry), ALABS" <gash@att.com>]

Alessio,

First, your example and questions are similar to those raised by Francois back in November.  E.g., see
http://ops.ietf.org/lists/te-wg/te-wg.2002/msg00245.html
http://ops.ietf.org/lists/te-wg/te-wg.2002/msg00247.html
http://ops.ietf.org/lists/te-wg/te-wg.2002/msg00248.html
http://ops.ietf.org/lists/te-wg/te-wg.2002/msg00251.html
http://ops.ietf.org/lists/te-wg/te-wg.2002/msg00268.html
etc.   Please take a look at the TEWG archive, and you'll see that discussion.

Regarding your specific example and questions:

> I have a question regarding 
> draft-ash-mpls-dste-bcmodel-max-alloc-resv-01 because
> i don't understand the action of bandwidth reservation mechanism.
> 
> You write:
> 
> Bandwidth allocated to individual CTs is protected as 
> needed but otherwise shared. Under normal non-congested network 
> conditions, all CTs/services fully share all available bandwidth. When 
> congestion occurs for a particular CTi, bandwidth reservation acts to 
> prohibit traffic from other CTs from seizing the allocated capacity for 
> CTi
> 
> Now look at this example: I suppose 3 CTs all with normal priority
> 
> CT0-BWalloc = 30
> CT1-BWalloc = 20
> CT2-BWalloc = 20
> Reserved Bandwidth (RBW) = 10
> 
> I suppose that :
> CT0 has taken 80 units of bandwidth
> CT1 has taken 5 units of bandwidth
> CT2 has taken 0 units of bandwidth
> 
> Let'me say a flow arrives for CT2 needing 20 units of bandwidth (i.e., DBW 
> = 5). I need to decide based on Table 2 and Table 1 whether to admit 
> this flow or not.
> 
> Table 2  says Bandwidth -Not -Allowed
> 
> In this situation is the request for CT2 refuse or not? 

As per Table 2, since the entire BW request=20 could not be admitted on this LSP, it could attempt alternate LSPs.  The request could be satisfied either entirely on an alternate LSP, or alternatively, the request could be satisfied with BW=5 on this (the primary) LSP, and BW=15 on an alternate LSP.

While the example you give is of course possible, it is not 'typical' or realistic in that this would be a rare event.  The example does not reflect the engineering of BWalloc according to bandwidth demand.  That is, it would be rare (although not impossible) for CT0 to need so much more BW (=80 in your example) than its BWalloc=30 (which is its engineered/expected BW level).  But if CT0 was that much above its engineered level, the expectation based on design and normal traffic fluctuations is that CT0 would quickly release unneeded bandwidth toward its BWalloc, freeing up bandwidth for other CTs.

Furthermore, your example has CT2 seizing its entire BWalloc=20 in one jump.  I'm not sure what traffic model you're assuming, but this would be highly atypical in an engineered network based on measured and forecast traffic demand.  

In doing BW allocation, the design of the BW limits and thresholds, for any of the BC models, must be based on BW demands of each CT.  That is, the engineering design of the BW allocation model by the user/service-provider must be based on some realistic traffic model to work properly. 

> How bandwidth reservation acts to 
> prohibit traffic from other CTs from seizing the allocated 
> capacity for CT2 ?
> I would understand if CT0 frees band so I can accept the 
> request for CT2.

Bandwidth reservation provides that a level of bandwidth will be available for CTs below their BWalloc to seize BW preferentially over CTs above their BWalloc.  The references in the I-D show how this works in practice, the technique is widely deployed.  

Also, your example has the bandwidth request = 20, which is much larger than the reserved RBW = 10.  So even if the RBW is available (which it isn't in your example), the request could not be satisfied anyway.  Again, I'm not sure what traffic model you're assuming, but this is quite atypical in an engineered network based on measured and forecast traffic demand, and a realistic traffic model. 

Finally, the draft has been revised http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-mar-00.txt (as agreed in the TEWG meeting and on the list) to add Section 3 on 'assumptions & applicability'.  This Section should help clarify the points made above in relationship to the questions you raised.  

Also, other changes have been incorporated in the updated I-D based on discussion/comments on the list (see separate post on changes).

Thanks,
Jerry