Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt

[Stephen Trowbridge <sjtrowbridge@lucent.com>]

Eric,
The point of my earlier email (items again below, this time with
numbers) was not to prompt the comment "#3 is out of scope, therefore
it is a choice between #1 and #2" (my parsing of recent statements).

The issue (and I think the reason for Maarten's strong reaction) is this:
GMPLS-LBM and LCAS are NOT different solutions to the same problem.
GMPLS-LBM and LCAS ARE solutions to different problems.
(I hope this is not too subtle for non-native English speakers).

LCAS is a method to hitlessly change the mappings at the two
ends of a virtually concatenated trail to increase or decrease the
bandwidth. It does not say anything about how components to be
added or removed from the virtually concatenated "bundle" are
set up or taken down.

LBM talks about how to set up or take down those added or removed
components, but not about the details of changing the mapping (other
than that it is done after the new components are successfully
established.

If you use LBM and change the mappings at the two ends without some
coordination such as LCAS, you will have a glitch to the traffic
(I think this is simple enough).

The compare/contrast discussion of LBM and LCAS is appropriate not
because LCAS is "sacred", but because you are comparing apples to
oranges. Statements in this document such as "One drawback of LCAS is .."
are unnecessary and inappropriate in this context, since LBM does
NOT solve the problem LCAS was designed to solve. Perhaps if you
were solving the SAME problem better, this would be OK, but this
is not the case.

Time to try to be constructive:
- I think most of the current discussion of LCAS should be removed from
this document. It is irrelevant since LCAS solves a different problem than
LBM. To say that one is "better" than the other would only be meaningful
if they were solving the same problem (can you really say that LBM solves
problem A better than LCAS solves problem B?).
- LCAS can be a good informative reference as a way to hitlessly modify
the size of a virtually concatenated trail.
- Clarify in the scope that the current draft describes the use of LBM
without LCAS, which results in a traffic glitch when bandwidth is modified.
Indicate that the use of LCAS to hitlessly negotiate the changes to
the size of virtually concatenated pipes after LBM sets up new component(s)
or before LBM takes down old component(s) is a topic for further study
and perhaps to be addressed in a future version of the draft.

Regards,
Steve

Steve Trowbridge wrote:
> 1. Can you use LBM without LCAS? Yes, if you don't mind a glitch to
> the traffic.
> 
> 2. Can you use LCAS without LBM? Yes, if you don't care whether the
> control plane knows that the different LSPs are part of the same
> circuit.
> 
> 3. Can you use LCAS WITH LBM? Hopefully yes, and this would seem to
> be the preferred method for many applications.


"Mannie, Eric" wrote:
> 
> Hello Maarten,
> 
> >Any sentence in which LCAS and ASON/GMPLS are compared shows a lack of
> >understanding of LCAS's objective (my very strong opinion).
> 
> Sorry, do you mean that it is forbidden to speak about your LCAS document
> and to compare GMPLS and LCAS functionalities ?
> 
<snip, to save BW>