Last call completed on draft-ietf-ccamp-gmpls-mln-reqs-05.txt
"Adrian Farrel" <adrian@olddog.co.uk> Tue, 25 September 2007 21:20 UTC
Return-path: <owner-ccamp@ops.ietf.org>
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IaHpi-0008Af-F4 for ccamp-archive@ietf.org; Tue, 25 Sep 2007 17:20:42 -0400
Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IaHph-0002JW-8R for ccamp-archive@ietf.org; Tue, 25 Sep 2007 17:20:42 -0400
Received: from majordom by psg.com with local (Exim 4.67 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1IaHg8-0009VY-Hu for ccamp-data@psg.com; Tue, 25 Sep 2007 21:10:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on psg.com
X-Spam-Level:
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.1
Received: from [212.23.8.67] (helo=fizeau.zen.co.uk) by psg.com with esmtp (Exim 4.67 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1IaHg5-0009VC-SA for ccamp@ops.ietf.org; Tue, 25 Sep 2007 21:10:47 +0000
Received: from [212.23.3.142] (helo=rutherford.zen.co.uk) by fizeau.zen.co.uk with esmtp (Exim 4.50) id 1IaHg4-00041u-V0 for ccamp@ops.ietf.org; Tue, 25 Sep 2007 21:10:44 +0000
Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by rutherford.zen.co.uk with esmtp (Exim 4.50) id 1IaHg3-0004Sp-IH for ccamp@ops.ietf.org; Tue, 25 Sep 2007 21:10:43 +0000
Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 25 Sep 2007 22:10:43 +0100
Message-ID: <003801c7ffb8$86c94070$0200a8c0@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: ccamp@ops.ietf.org
Cc: Kohei Shiomoto <Shiomoto.Kohei@lab.ntt.co.jp>, Dimitri Papadimitriou <Dimitri.Papadimitriou@alcatel-lucent.be>, Jean-Louis Le Roux <jeanlouis.leroux@orange-ftgroup.com>, Martin Vigoureux <Martin.Vigoureux@alcatel-lucent.fr>, "Brungard, Deborah A, ALABS" <dbrungard@att.com>
Subject: Last call completed on draft-ietf-ccamp-gmpls-mln-reqs-05.txt
Date: Tue, 25 Sep 2007 22:10:30 +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.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 25 Sep 2007 21:10:43.0212 (UTC) FILETIME=[887A24C0:01C7FFB8]
X-Originating-Rutherford-IP: [88.96.235.138]
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
X-Spam-Score: 0.2 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Hi, Working group last call completed on draft-ietf-ccamp-gmpls-mln-reqs-05.txt and draft-ietf-ccamp-gmpls-mln-eval-03.txt with a few comments to consider. The question was raised about the naming of "virtual TE links." It was suggested that "potential" be considered as a more appropriate word, partly because of the existing overload of "virtual" in various contexts, and partly to tie in with the ASON use of terminology. Could the authors please think about this and propose a resolution. We also received some comments from the ITU-T in their liaison https://datatracker.ietf.org/liaison/368/. They raise some issues for our consideration and the authors need to address these points so that they can update the I-D if necessary, and so we can respond to the ITU-T as necessary. Adaptation - They suggest that we should include a definition of Adaptation. - They suggest advertising the adaptation capability/ies of a link in place of the switching capabilities. I am confused by this because I would have thought that both pieces of information are needed. It may be that the ITU-T are assuming that the technology layer is known a priori. It is certainly the case that multiple switching or adaptation capabilities should be able to be advertised on a single link, and I think this is in the I-Ds, but maybe it needs clarification. - Abstract representations of layers and adaptations may be advantageous. Although this might be a solution-specific issue, if there are requirements they should be drawn out. Virtual Node The ITU-T suggests that the virtual node model might be applied as a solution architecture alongside the virtual links. Maybe the requirements draft could include some comments on this. Thanks, Adrian
- Last call completed on draft-ietf-ccamp-gmpls-mln… Adrian Farrel
- Re: Last call completed on draft-ietf-ccamp-gmpls… Kohei Shiomoto