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
- Draft response to ITU-T on VCAT Adrian Farrel
- Re: Draft response to ITU-T on VCAT Greg Bernstein