RE: Example of LOM usage

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

Jerry,

<clip>
>> I'm a little baffled by this whole discussion.  A reasonable 
>> question was asked to provide justification for LOM.  In the 
>> ensuing discussion, most agreed that LOM is not complicated, 

I am losing track as to whether LOM is declared complicated or simple ^)

In any case, as mentioned before, the point at stake is not whether it
is inherently simple or complicated. (FWIW my take is that it is pretty
much as simple as could be to do what it has to do). The point at stake
is: does the extra functionality justifies the extensions (like the
extra IGP extensions for example) when we had been designing DSTE very
carefully to minimise IGP impact so far.

>> and we have been given some reasonable examples of why/how 
>> it would be applied. 

So, we've been calling for input on the whole list several times for who
would/may have a practical case for this and all we got is one single
input (which considered potential pros based on Erlang's formula but BTW
did not discuss potential cons on the practical/operational side such as
managing Nb_of_CTs-times-Nb_of_links additional configurable parameters,
additional IGP information). 

Based on this level of input, I wouldn't say that there is a clear
justification for the extra functionality which would justify the
corresponding extensions.

<clip>
>> There are still lots of questions surrounding the 
>> idea of splitting off LOM into a parallel effort.  

I sent a message earlier specifically on this recurring statement.
The proposal is to take the text that is currently in -proto-, -russian
and -mam (and on MAR if you want) on LOM and group that in a separate
document which could then go as Experimental.
It would be the same text.
What exactly are the questions surrounding this idea?

>> Since LOM 
>> is already in the Proto spec, that is the easier option.  
>> There does not seem to be a lot of justification now for 
>> splitting it off, especially given that its use has been 
>> illustrated.  Let's go with leaving it in, as is, and move on.
>> 

To me, and I suspect to the other folks who argued for taking LOM out,
the level of input (or lack of) we got so far is actually indeed
justification for taking it off the main specs. And even, at least to
me, justification to drop it altogether.

So, we really see things differently here. 

Documenting LOM as Experimental is an attempt at a compromised approach
to try move ahead considering this disagreement. It would allow folks
who see it as something worthwhile to have it documented so it can be
experimented with, and even easily added to standards track in some
future if backed by experience. It would allow folks who question the
practical use of LOM to see a leaner DS-TE solution (at least to start
with). 

Assuming we can close-off the potential questions you may have
surrounding the idea of splitting LOM in a separate document, could you
live with this compromised approach of an Experimental track for LOM?

Thanks

Francois