RE: [Mavs] MAVS Requirements Draft posted

"JACQUENET Christian RD-TCH-REN" <christian.jacquenet@francetelecom.com> Tue, 14 February 2006 16:17 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92rz-0008Ec-TC; Tue, 14 Feb 2006 11:17:39 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F92rx-0008Cr-Tq for MAVS@megatron.ietf.org; Tue, 14 Feb 2006 11:17:38 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07899 for <MAVS@ietf.org>; Tue, 14 Feb 2006 11:15:52 -0500 (EST)
Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F935k-0007BG-CW for MAVS@ietf.org; Tue, 14 Feb 2006 11:31:56 -0500
Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 17:17:30 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Mavs] MAVS Requirements Draft posted
Date: Tue, 14 Feb 2006 17:17:26 +0100
Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A0945D177@FTRDMEL2.rd.francetelecom.fr>
Thread-Topic: [Mavs] MAVS Requirements Draft posted
Thread-Index: AcYxA9b8N+pBWaT1Th2LMSIVq/HklwAAKfKg
From: "JACQUENET Christian RD-TCH-REN" <christian.jacquenet@francetelecom.com>
To: <dpapadimitriou@psg.com>, <dimitri.papadimitriou@alcatel.be>
X-OriginalArrivalTime: 14 Feb 2006 16:17:30.0971 (UTC) FILETIME=[27CA32B0:01C63182]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Content-Transfer-Encoding: quoted-printable
Cc: MAVS@ietf.org, "Jim Guichard \(jguichar\)" <jguichar@cisco.com>
X-BeenThere: mavs@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiprovider End-to-end VPN Services <mavs.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mavs>, <mailto:mavs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mavs>
List-Post: <mailto:mavs@ietf.org>
List-Help: <mailto:mavs-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mavs>, <mailto:mavs-request@ietf.org?subject=subscribe>
Sender: mavs-bounces@ietf.org
Errors-To: mavs-bounces@ietf.org

Dimitri,

Many thanks for your comments...and for re-activating this list :-) More below. 

-----Message d'origine-----
De : dimitri papadimitriou [mailto:dpapadimitriou@psg.com] 
Envoyé : mardi 14 février 2006 02:12
À : JACQUENET Christian RD-TCH-REN
Cc : MAVS@ietf.org; Jim Guichard (jguichar)
Objet : Re: [Mavs] MAVS Requirements Draft posted

hi christian,

there is indeed lot's of progress achieved in terms of requirements for 
activating multi-AS/SP VPNs; imho, starting with topological, security 
and management should received most of the attention (as first step);

CJ: thanks for your encouragement - I'm sure all the editors will appreciate :-)

concerning "QoS" it would be appropriate to come with a sort of first 
layout because as far as my memory goes a discussion had been initiated 
in Yokohama on QoS for VPN that lead to a short section in RFC4364 and 
as the document also explains very few is available in terms of std's on 
which this multi-AS/SP QoS could rely on; so, from the QoS perspective 
the starting point is different than for inst. the topological aspects

CJ: I'm not sure I fully understand this comment. In the QoS section, we tried to insist on the current issues and requirements we'd like to deal with as far as the provisioning of inter-domain VPN services with the required level of quality (as expressed and potentially negotiated with the customer) is concerned. What we tried to suggest is, e.g., to encourage the ability of exhanging of QoS information between domains assuming common understanding of such information, hence hopefully yielding a *consistent* metrology to qualify how efficiently a VPN-specific QoS policy is enforced, based upon commonly understood QoS indicators, for example. So, the "layoout" you mention in your comment could consist in encouraging the standardization of a SLS template to (reliably) exchange (and negotiate) QoS information not only between a customer and a specific VSP, but also between VSPs.

the provided classification and the selected items should be completed 
by a detailed work plan with set of "actions" that would be part of a 
charter

relationship with the work carried out as part of other working groups 
(SIDR, DCP, etc.) could then be determined

CJ: agreed.

i would be willing to help in this process

CJ: cool, let me suggest you send the editors the corresponding text of this presumably new section of the draft.

Cheers,

Christian.

_______________________________________________
Mavs mailing list
Mavs@ietf.org
https://www1.ietf.org/mailman/listinfo/mavs