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
- RE: LBM comment Heiles Juergen
- RE: LBM comment Brungard, Deborah A, ALASO
- Re: LBM comment Maarten Vissers
- Re: LBM comment Sudheer Dharanikota
- RE: LBM comment Bernstein, Greg
- LBM comment Maarten Vissers