RE: LBM comment

"Bernstein, Greg" <GregB@ciena.com> Wed, 20 March 2002 17:02 UTC

Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 20 Mar 2002 09:03:41 -0800
Message-ID: <2135200C183FD5119588009027DE5723DD4B61@wntcsdexg02.csd.ciena.com>
From: "Bernstein, Greg" <GregB@ciena.com>
To: 'Maarten Vissers' <mvissers@lucent.com>, ccamp <ccamp@ops.ietf.org>
Subject: RE: LBM comment
Date: Wed, 20 Mar 2002 09:02:55 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"

Hi all, to reiterate what Maarten points out below: "LCAS takes care of the
hitless addition/removal of this trail to/from the virtual concatenated
group in service.".  Eric's statement concerning LCAS being between
PTE-to-PTE also applies to Virtual Concatenation in general.  
Hence the SONET LTE layer (SDH MS termination) switches, i.e., most of the
ADMs and XCs out there don't care that the signal is virtually concatenated.
Hence all the current stuff in the SONET/SDH signaling extensions concerning
virtual concatenation is just end system information and not needed by the
network.
Is the LBM work really aimed at the virtual concatenated case? If so it
seems unnecessary. Also instead of further complicating connection signaling
couldn't we abstract things a bit to have some type of grouping/association
of multiple (pt-to-pt) connections together rather than changing the
signaling protocol?

Greg B.

-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Wednesday, March 20, 2002 8:29 AM
To: ccamp
Subject: LBM comment


Not having had time earlier to read the LBM draft, I only just came across
some
still VERYY INCORRECT text in draft-mannie-ccamp-gmpls-lbm-tdm-01.txt.

>From section 3:

   "LCAS is an end-to-end (i.e. PTE-to-PTE) signalling protocol enabling
   the bandwidth modification at end systems and setting up and
   releasing circuits provisioned and configured through Network
   Management Systems (NMS). However, LCAS doesn't apply to setting up
   and releasing bandwidth at intermediate nodes. This means that LCAS
   must be combined with an NMS system in order to offer a dynamic
   connection setup throughout the network. Therefore, the advantage of
   using GMPLS is that it provides a complete integrated solution,
   allowing for a wide range of traffic parameter modifications."

LCAS MUST NOT AT ALL BE COMBINED WITH NMS!!!!!!!!!!!!!! LCAS must be
combined
with either NMS or ASON or GMPLS, which latter 3 take care of the set up or
release of a VC-n or ODUk trail. LCAS takes care of the hitless
addition/removal
of this trail to/from the virtual concatenated group in service.


>From section 3:

   "Using LCAS in parallel with GMPLS implies that GMPLS traffic
   parameters may be modified without the GMPLS control plane being
   aware of these modifications. However, GMPLS provides native
   capabilities to modify traffic parameters of an established LSP
   since MPLS-TE signalling was originally conceived to allow traffic
   parameter (bandwidth) modification."

Using LCAS does *NOT* at all imply that GMPLS traffic parameters are
modified.
NMS/ASON/GMPLS are in full control of the connections setup to support the
virtual concatenated group.

Regards,

Maarten