AW: LCAS and GMPLS

[Michael.Dueser@t-systems.com]

Hi Trevor,

you're right! Thanks for the clarification,

Michael




-----Ursprüngliche Nachricht-----
Von: Trevor Wilson [mailto:wilsont@nortel.com] 
Gesendet: Mittwoch, 27. Juli 2005 13:31
An: Wataru Imajuku; Dueser, Michael; ccamp@ops.ietf.org
Betreff: RE: LCAS and GMPLS


Hi,

VCAT (and LCAS) functionality is required ONLY at the terminating TDM NEs of a Virtually Concatenated signal. As long as the 'intermediate NEs', through which the individual VC-ns are transported, have the capacity to carry those VC-ns then the SONET/SDH network will provide the necessary connection. For any given VCAT connection, the intermediate NEs do not need to be VCAT/LCAS capable. Therefore I do not understand why, in the 'problem statement of 'draft-imajuku-ccamp-gmpls-vcat-lagr-req-00.txt', each TDM node should advertise its VCAT/LCAS capabilities. When the connection is being provisioned, it is up to the SDH/SONET NMS to determine whether or not the network (and it's NEs) are capable of a VCAT/LCAS operation. In the TDM network, label switching is not performed, except perhaps at the edge of the network where the client signal is encapsulated into the transport technology. Therefore I believe that the routes for the individual VC-ns of a virtually concatenated group (VCG) are of no consequence to the client signal, and the VCG can be looked upon as a single LSP between the TDM ingress node and the TDM egress node.

Michael:

Below you state that LCAS is Bi-directional.
For LCAS to operate it needs at least one member in both directions; but essentially the LCAS operation is uni-directional in nature. If bandwidth adjustment is required in both directions it is necessary to initiate these separately.

Regards,

Trevor

Trevor Wilson
Nortel Networks
Belfast Lab
Tel: +44 2890 363701
       ESN 751 3701
>This is the Way. This is Nortel.
>


-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Wataru Imajuku
Sent: 27 July 2005 05:28
To: Michael.Dueser@t-systems.com; ccamp@ops.ietf.org
Subject: Re: LCAS and GMPLS


Hi, Mr. Dueser and all

  Thank you for your comment.

  As you pointed out, the GFP/LCAS/VCAT functionality is temination
capability.
  But, it can easily migrate with non-GFP/LCAS/VCAT TDM network,

  The one of ID's requirements includes the extension for the routing
protocol in order to advertise such termination capability in each node.
  I believe this routing extension helps smooth migration amongst
GFP/LCAS/VCAT capable and non capable networks.

  In the -00.txt version, the ID suggests the extension to
  Interface Switching Capability Descriptor (ISCD) as a temporal
suggestion.
  Because, I understand that the meaning of interface switching
capability 
descriptor
  includes both transit capability and termination capability of LSPs.

  However, the explicit addition of termination capability to the ISCD
may 
be one of choice,
considering the more generic node architeture as discussed in Dimitri's 
MRN-extensions draft.

  I hope the discussion in Paris meeting also for above issue .

Best Regards,
Wataru

Hi,

>some comments re I-D draft-imajuku-ccamp-gmpls-vcat-lagr-req-00:
>
>- LCAS was not intended for grouping of VC-X-yvs, but for 
>synchronization
>of the VC-X which is added or dropped. And it's bi-directional.
>- Only the terminating nodes need to have the full GFP+LCAS+VCAT
functionality.
>- You need to be careful when using the verbs may, shoul and must - are

>they conform to IETF convention?
>
>I believe in general this is an important I-D also wrt to the ITU-T
>liaison and for implementation! I believe we can also discuss details 
>during the IETF next week.
>
>Michael Dueser

---------------------------------
Wataru Imajuku
Senior Research Engineer
@NTT Network Innovation Labs.
TEL +81-46-859-4315
FAX +81-46-859-5541