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