RE: [L1vpn] Proposed charter for L1VPN WG

Dimitri.Papadimitriou@alcatel.be Fri, 06 May 2005 15:07 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24130 for <rtg-dir-archive@ietf.org>; Fri, 6 May 2005 11:07:01 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4eR-0002CU-EP for rtg-dir-archive@ietf.org; Fri, 06 May 2005 11:22:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4PC-0003Nu-WE; Fri, 06 May 2005 11:06:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4PA-0003MI-Mp; Fri, 06 May 2005 11:06:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24024; Fri, 6 May 2005 11:06:13 -0400 (EDT)
From: Dimitri.Papadimitriou@alcatel.be
Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4dg-0002Bj-ME; Fri, 06 May 2005 11:21:17 -0400
Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j46F6ALD016085; Fri, 6 May 2005 17:06:13 +0200
To: Hamid Ould-Brahim <hbrahim@nortel.com>
MIME-Version: 1.0
Date: Fri, 06 May 2005 17:06:09 +0200
Message-ID: <OF61D28A5A.BE8E7B18-ONC1256FF9.0052F57C-C1256FF9.0052F609@netfr.alcatel.fr>
X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 05/06/2005 17:06:13
MIME-Version: 1.0
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Alcanet-MTA-scanned-and-authorized: yes
X-Spam-Score: 4.8 (++++)
X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64
Content-Transfer-Encoding: base64
Cc: Alex Zinin <zinin@psg.com>, rtg-dir@ietf.org, l1vpn@ietf.org, Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>
Subject: RE: [L1vpn] Proposed charter for L1VPN WG
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
Sender: rtg-dir-bounces@ietf.org
Errors-To: rtg-dir-bounces@ietf.org
X-Spam-Score: 4.8 (++++)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: base64

hamid -

the framework document has been used to determine the protocol work this group is going to address, if two documents (requirements + framework) are to be progressed in parallel it means that either

- you suggest we keep continuing work on functional requirements but then one could question whether we agree on what to do in this working group ? (note: protocol details will be worked out as part of the protocol work anyway)

- or you do suggest that we close the requirements asap (but then what is the purpose of it as we would be all in agreement ? here also details will be worked out as part ofthe protocol work anyway) and the framework becomes the document where terms, working assumptions and other models get documented as suggested in the initial charter proposal

would you clarify your thought because i have some difficulties to understand the logic behind the below reasoning ?

"Hamid Ould-Brahim" <hbrahim@nortel.com>
Sent by: rtg-dir-bounces@ietf.org
05/06/2005 09:39 AST

To: Tomonori TAKEDA <takeda.tomonori@lab.ntt.co.jp>, Alex Zinin <zinin@psg.com>
cc: rtg-dir@ietf.org, l1vpn@ietf.org
bcc:
Subject: RE: [L1vpn] Proposed charter for L1VPN WG


Tomonori,

>
> I think framework document can describe service requirements.
>
> Curret framework document (draft-takeda-l1vpn-framework-03) already
> contains service requirements. There may be some detailed
> points to be
> discussed, especially for the enhanced mode (sig+rtg model),
> as we see some
> discussion. (Framework document is describing a broad range
> of things, but
> not at the level of protocol requirements.) So, it may be
> necessary to
> narrow down the scope for the enhanced mode, which can be
> done through the
> mailing list, or if needed, through writing a separate draft.
> (I don't
> think we have an immediate need to write a separate draft.)
>

I do agree the framework draft covers the requirements and is inline
with ITU L1VPN work. An option that can be considered is to separate
the requirements from the framework in separate internet draft and
let the two drafts progress independently (from work point of view).
I assume at certain point solutions (and not the framework) would have
to be compared to the set of requirements listed.

Hamid.