RE: [Mavs] MAVS Requirements Draft posted

"JACQUENET Christian RD-TCH-REN" <> Tue, 14 February 2006 16:17 UTC

Received: from ([] by with esmtp (Exim 4.32) id 1F92rz-0008Ec-TC; Tue, 14 Feb 2006 11:17:39 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1F92rx-0008Cr-Tq for; Tue, 14 Feb 2006 11:17:38 -0500
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id LAA07899 for <>; Tue, 14 Feb 2006 11:15:52 -0500 (EST)
Received: from ([]) by with esmtp (Exim 4.43) id 1F935k-0007BG-CW for; Tue, 14 Feb 2006 11:31:56 -0500
Received: from ([]) by 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: <>
Thread-Topic: [Mavs] MAVS Requirements Draft posted
Thread-Index: AcYxA9b8N+pBWaT1Th2LMSIVq/HklwAAKfKg
From: JACQUENET Christian RD-TCH-REN <>
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:, "Jim Guichard (jguichar)" <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiprovider End-to-end VPN Services <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


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

-----Message d'origine-----
De : dimitri papadimitriou [] 
Envoyé : mardi 14 février 2006 02:12
Cc :; 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 

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.



Mavs mailing list