[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [T1X1.5] Re: LCAS and draft-mannie-ccamp-gmpls-lbm-tdm-00.txt
Agree with Steve-
LCAS requires "provisioned" capacity; it makes use of allocated capacity as
needed. LCAS can not provision capacity end-to-end (intermediate nodes); it
is transparent to intermediate equipment. It applies to the end points (path
termination per ITU-T definition - not GMPLS links). And it is defined for
data mappings (e.g. GFP for Ethernet/SAN support). As Steve says -
comparing LCAS and GMPLS-LBM would be like comparing a data transport
mapping with EMS/NMS functionality. GMPLS should support LCAS, similar to
any other mapping. Dimitri had valid quotes..looking at T1.105, it refers to
LCAS as a protocol, though does not say the type..in T1X1.5's definitions,
it is a protocol similar to APS. For questions on LCAS or if clarifications
are identified for the T1.105 text, send email to the T1X1.5 exploder (open
for non-members).
T1.105 pre-pub draft is available (LCAS is in Annex B):
ftp://ftp.t1.org/T1X1/2001x15/1X150620.DOC
T1X1 files are at:
http://www.t1.org/t1x1/_x1-grid.htm
The next T1X1 meeting is the week of Jan. 21:
http://www.t1.org/t1x1/jan2002.htm
We previously scheduled two "lunch-time" seminars which may be of interest
here. If you can not attend the meeting - the presentations will be uploaded
to the T1X1.5 files:
- GFP/virtual concatenation/LCAS
- ASON
The presentations will provide a summary of the recent ITU-T SG15 meeting
and on-going work.
Deborah Brungard
AT&T
(T1X1.5 Chair)
-----Original Message-----
From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
Sent: Friday, November 16, 2001 1:49 PM
To: Mannie, Eric
Cc: 'Maarten Vissers'; ccamp; q11/15; t1x1.5; Dimitri Papadimitriou
Subject: [T1X1.5] 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>