Draft response to ITU-T on VCAT

"Adrian Farrel" <adrian@olddog.co.uk> Fri, 29 August 2008 18:19 UTC

Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 4E1AD3A6A3B for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 29 Aug 2008 11:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.641
X-Spam-Status: No, score=0.641 tagged_above=-999 required=5 tests=[AWL=-0.354, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Qp0La8RYCP-s for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 29 Aug 2008 11:19:23 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 393133A6A47 for <ccamp-archive@ietf.org>; Fri, 29 Aug 2008 11:19:23 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KZ8Rp-000HhL-CO for ccamp-data@psg.com; Fri, 29 Aug 2008 18:11:49 +0000
Received: from [] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1KZ8Ri-000Hfh-P7 for ccamp@ops.ietf.org; Fri, 29 Aug 2008 18:11:46 +0000
Received: from asmtp2.iomartmail.com (localhost.localdomain []) by asmtp2.iomartmail.com ( with ESMTP id m7TIBLu3016665; Fri, 29 Aug 2008 19:11:21 +0100
Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com []) (authenticated bits=0) by asmtp2.iomartmail.com ( with ESMTP id m7TIBKTX016657; Fri, 29 Aug 2008 19:11:20 +0100
Message-ID: <0ac301c90a02$a226bd70$0300a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Cc: "Brungard, Deborah A, ALABS" <dbrungard@att.com>, "Ross Callon" <rcallon@juniper.net>, <dward@cisco.com>, "Scott Bradner" <sob@harvard.edu>
Subject: Draft response to ITU-T on VCAT
Date: Fri, 29 Aug 2008 19:10:40 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>


We have a liaison to respond to from the ITU-T on VCAT 

Please a draft response below.
Comments to me by Friday September 5.



The IETF CCAMP working group thanks you for your liaison on GMPLS control of 
VCAT/LCAS dated February 1st 2008, and received February 29th.

Please find our responses in line.

> Here are our comments to the responses provided in your liaison:
> a) Regarding your response to Question 1 on protocol
>    extensibility to encompass technologies other than
>    SONET/SDH, we notice that the recent I-D
>    (draft-ietf-ccamp-gmpls-vcat-lcas-04.txt) limits the
>    number of VCGs per call to one. We support this
>    position and consider this to be a VCAT call.

Thank you. Your support is noted.

> b) Regarding your response to Question 4 on multiple calls
>    support, VCAT is viewed as a layer of its own and has its
>    own call controller.
>    As per the interlayer architecture in G.8080 section 6.6,
>    the VCAT call would be associated with a server layer call
>    or calls, each of which would have/own one or more server
>    layer connections.  It is these connections that are part of the
>    VCG. In retrospect, a single call is sufficient for diverse
>    routing as it can hold details of both connections so that they
>    don't use the same resources.
>    An example where multiple server calls associated with one
>    VCAT call would be useful is when all VCAT connections
>    are to be protected.
>    Here, rather than one call maintain the knowledge of all
>    working/protection pairs, it is simpler to have multiple calls
>    each of which only maintains one working/protection pair.
>    This is even more convenient when restoration behavior is
>    applied when the protection connection fails.

We note that in a functional architecture it makes good sense to separate 
the VCAT layer from the server/protection layer. We also observe that the 
protocol solution does not need to be tied rigidly to the functional 
architecture where optimizations may be made from collapsing layers into a 
single set of protocol exchanges.

> c) Regarding your response to Question 6 on IP address format in
>    GMPLS, we suggest the I-D clarifies that there are different name
>    (or identifier) spaces even though they may all use the same IP
>    address format, e.g.
>    - Control component
>      The identifiers used to identify the entities that perform the 
> control
>      plane functions, such as route computation, signaling, control plane
>      message delivering, etc.
>    - Transport resource
>      The identifiers used to identify transport resource when they are
>      referred to in the control plane messages. Note that these 
> identifiers
>      may not be the same as those referred to in the management plane
>      messages.
>    - SCN
>      The addresses used to deliver control plane messages
>    Examples of a similar address format in use in two different name
>    spaces can be seen in the OSPF routing protocol, where router ID
>    (control and transport link scope) and IP address (used by the
>    forwarder) do not have to be the same.

While we understand that these distinctions are not clear from reading this 
particular Internet-Draft, we believe that the distinction is clear from the 
weight of GMPLS RFCs. However, we thank you for pointing out that further 
clarity could be achieved, and will look at ways to add text to this 

The CCAMP working group is currently entering the final phase of work on 
this topic. The current version of the draft can be seen at 
and we would welcome any final input from ITU-T SG15 before we complete the 
publication process. With that in mind, we invite you to review this 
document and send us any comments before our November meeting. The response 
date to this liaison is set accordingly.