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

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Hello Stephen

> GMPLS-LBM and LCAS ARE solutions to different problems.

No, please see explanations below.

> 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).

No, please see below (C2 or V5 transition).

>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.

No, please see below.

Simple example:

1) you first signal an additional VC/SPE to the destination (via a Path).
2) the destination knows exactly which VC/SPE is added (via the label).
3) the new VC is unequipped (indicated in POH C2 (for HOVC)),
   so the VC/SPE is not yet added to concatenated signal.
4) then, you wait at the source for a confirmation from the destination
(i.e. Resv).
5) the source "equip" the VC/SPE and sends.
6) the destination sees in the POH that the VC is "equipped" (transition).

The difference between LCAS and LBM is that LCAS uses an additional explicit
indication in the overhead to say "this is the payload" to use. LBM doesn't
change the SDH/SONET overhead, while LCAS changes the SDH/SONET overhead :-)

LCAS uses a new field in the POH (CTRL) to know when the new VC transitions
to a significant payload. LBM proposes to do the same simply by looking at
the C2 (for HOVC) transition - regular SDH/SONET field that will change
anyway and that is used to indicate the type of payload.

To be more precise about LCAS (I copy from the LCAS specification, section
6.3.1): "The first container frame to contain payload data for the new
member shall be the container frame immediately following the container
frame that contained the last bit(s) (i.e. the CRC) of the control packet
with NORM/EOS message for that member" (the LCAS control packet).

So, LCAS waits for the last bit of the appropriate LCAS control packet in
the POH with the appropriate transition of its CTRL field. LBM waits simply
for the appropriate C2 (for HOVC) or V5 (for LOVC) transition in the POH
(don't change SDH/SONET).

By the way, this is version 0 of the draft and it was just posted.

Suggestions, technical comments and improvements are welcome.

I would appreciate if people could first read and speak before shooting
directly :-)

Kind regards,

Eric

-----Original Message-----
From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent: Friday, November 16, 2001 7:49 PM
To: Mannie, Eric
Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou
Subject: Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt


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>