RE: Example of LOM usage

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

Hello Jerry,

>> In the interest of moving ahead, I'm OK with the compromise 
>> to split off LOM from the Proto and BC drafts, and progress 
>> it separately on an Experimental track.  
>> 

So we'll update asap the -proto, -russian and -mam drafts:
	- (i) removing all the LOM staff and 
	- (ii) reflecting our agreement regarding the use of Max
Reservable Bandwidth

>> However, I do not agree that the starting point for the 
>> separate effort on LOM should be the current proposal.  
>> While I believe the concept of having a separate per-link, 
>> per-CT adjustment for overbooking, such as proposed with 
>> LOM, is worth pursuing, I also believe that the particular 
>> implementation proposed in Proto is problematic, and needs a 
>> re-work.  In particular, 
>> 
>> 1. It's not at all clear what 'normalized CTc' really means: 
>> it's not reserved BW, it's not overbooked bandwidth, what is 
>> it?  It's not a physical quantity, which makes it abstract 
>> and confusing.
>> 
>> 2. The router reserves Tspec(LSPc) (i.e., 
>> reserved(LSPc)=Tspec(LSPc), what does it do with normalized CTc?
>> 
>> 3. It's not at all clear what SUM [normalized_CTc] should be 
>> constrained by.  Neither Maximum Reservable Bandwidth (MRBW) 
>> nor Maximum Link Bandwidth seem correct.
>> 
>> 4. It's not at all clear how to set BCc in terms of 
>> normalized_CTc, how should that be done, and how do the BCs 
>> relate to MRBW?
>> 
>> If you can shed any light on these issues 1 --> 4, with some 
>> specific numerical examples, please do.
>> 
>> It is much easier to understand physical quantities like 
>> reserved_CTc, what they should sum to (MRBW), how they 
>> related to BCs, etc.
>> 
>> I think the concepts proposed in the post on June 1 
http://ops.ietf.org/lists/te-wg/te-wg.2003/msg00321.html 
>> have merit, and should be considered in the re-initiated effort 
>> on LOM.  Wai Sum and I have expanded this proposal in an I-D that 
>> we will soon submit for discussion.  The proposed approach is
coherent, 
>>I believe, while the current approach is not.  I think the I-D with
our 
>> proposal for LOM should be considered in this effort.

Since it no longer impacts progress of the base DS-TE specs, I don't see
a major issue in reopening the discussion on what is the best LOM
solution, and in your proposal being considered.

I think the current LOM solution which we've had stable for a long time
in our Working Group documents is the most natural starting point until
it is actually shown "problematic" and that another proposal is
superior. So let's have the discussion first on the LOM approaches
before switching to a new proposal.

In the very short term, I'd like to focus on issuing the base specs. So
I'll get back to your points above re current LOM approach a little
later and will also look into your proposal in more details then.

Thanks

FRancois