Re: Draft response to ITU-T on VCAT

Greg Bernstein <gregb@grotto-networking.com> Tue, 02 September 2008 14:50 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 [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81B003A69FB for <ietfarch-ccamp-archive@core3.amsl.com>; Tue, 2 Sep 2008 07:50:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWhgo6pqNG7V for <ietfarch-ccamp-archive@core3.amsl.com>; Tue, 2 Sep 2008 07:50:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 708893A68CE for <ccamp-archive@ietf.org>; Tue, 2 Sep 2008 07:50:13 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KaX4K-0004lo-MW for ccamp-data@psg.com; Tue, 02 Sep 2008 14:41:20 +0000
Received: from [66.226.64.47] (helo=pro46.abac.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <gregb@grotto-networking.com>) id 1KaX4C-0004l1-0s for ccamp@ops.ietf.org; Tue, 02 Sep 2008 14:41:18 +0000
Received: from [192.168.0.131] (c-71-202-41-42.hsd1.ca.comcast.net [71.202.41.42]) (authenticated bits=0) by pro46.abac.com (8.14.3/8.14.3) with ESMTP id m82Ees9T099754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Sep 2008 07:40:58 -0700 (PDT) (envelope-from gregb@grotto-networking.com)
Message-ID: <48BD5077.3060400@grotto-networking.com>
Date: Tue, 02 Sep 2008 07:40:55 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
CC: ccamp@ops.ietf.org, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Re: Draft response to ITU-T on VCAT
References: <0ac301c90a02$a226bd70$0300a8c0@your029b8cecfe>
In-Reply-To: <0ac301c90a02$a226bd70$0300a8c0@your029b8cecfe>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>

Adrian and Deborah, this looks good.

Thanks

Greg B.

Adrian Farrel wrote:
> Hi CCAMP,
>
> We have a liaison to respond to from the ITU-T on VCAT 
> (https://datatracker.ietf.org/liaison/429/).
>
> Please a draft response below.
> Comments to me by Friday September 5.
>
> Thanks,
> Adrian
>
> =====
>
> 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 document.
>
> 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 
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-05.txt 
> 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.
>
>
>
>
>
>

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237