Re: [pm-dir] PM-DIR Review for draft-ietf-nvo3-framework-06.txt

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Fri, 30 May 2014 10:29 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: pm-dir@ietfa.amsl.com
Delivered-To: pm-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58F41A06F7; Fri, 30 May 2014 03:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.25
X-Spam-Level:
X-Spam-Status: No, score=-3.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_8LKGvmKY-M; Fri, 30 May 2014 03:29:25 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6740A1A0028; Fri, 30 May 2014 03:29:25 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmUGAIRciFOHCzIm/2dsb2JhbABZgkIjIlJYqhUBAQEBAQEGmBkBgQkWdIIlAQEBAQMSG0wQAgEIDQQEAQELHQcyFAkIAQEEAQ0FCBMHiCABp0OvOBeFVYhMMQYBgyuBFQSVd4sZjBaDOIIv
X-IronPort-AV: E=Sophos; i="4.98,940,1392181200"; d="scan'208,217"; a="65551653"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 30 May 2014 06:29:19 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 30 May 2014 06:27:09 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Fri, 30 May 2014 12:29:18 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "LASSERRE, MARC (MARC)" <marc.lasserre@alcatel-lucent.com>, "nvo3@ietf.org" <nvo3@ietf.org>
Thread-Topic: PM-DIR Review for draft-ietf-nvo3-framework-06.txt
Thread-Index: Ac96dCxQ7OAlmfDXT02hcVeTz06jFwBZ4PlgAAVlGoA=
Date: Fri, 30 May 2014 10:29:17 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C7F5467@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA5C7F328F@AZ-FFEXMB04.global.avaya.com> <B30152B129674240ADF67727A967301408C6A1@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <B30152B129674240ADF67727A967301408C6A1@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.46]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C7F5467AZFFEXMB04globa_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/pm-dir/FbvlYpL0JPus-WCYlmn-AJxro04
Cc: Benoit Claise <bclaise@cisco.com>, "pm-dir@ietf.org" <pm-dir@ietf.org>
Subject: Re: [pm-dir] PM-DIR Review for draft-ietf-nvo3-framework-06.txt
X-BeenThere: pm-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Performance Metrics Directorate Discussion list <pm-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pm-dir/>
List-Post: <mailto:pm-dir@ietf.org>
List-Help: <mailto:pm-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pm-dir>, <mailto:pm-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 May 2014 10:29:28 -0000

Hi,

Thank you for the response and for addressing my comments.

See in-line.

Regards,

Dan


From: LASSERRE, MARC (MARC) [mailto:marc.lasserre@alcatel-lucent.com]
Sent: Friday, May 30, 2014 11:21 AM
To: Romascanu, Dan (Dan); nvo3@ietf.org
Cc: Benoit Claise; pm-dir@ietf.org
Subject: RE: PM-DIR Review for draft-ietf-nvo3-framework-06.txt

Hi Dan,

Thanks for your feedback.
See my comments below.

Marc

________________________________
From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Wednesday, May 28, 2014 2:56 PM
To: nvo3@ietf.org<mailto:nvo3@ietf.org>
Cc: Benoit Claise; pm-dir@ietf.org<mailto:pm-dir@ietf.org>
Subject: [nvo3] PM-DIR Review for draft-ietf-nvo3-framework-06.txt
This is the PM-DIR review for draft-ietf-nvo3-framework-06.txt. I am the assigned PM-DIR reviewer for this I-D. This review refers only to performance metrics aspects

This I-D defines a framework for Network Virtualization Overlays (NVO3) and a reference model along with logical components required to design a NVO3 solution.


The I-D does not define performance metrics, so a RFC 6390 review does not apply.

Performance metrics are mentioned in one place in the document, in section 5.2.6 which deals with the interaction between overlays and underlays and the need to exchange information about performance in order to ensure that the overlays requirements can be met by the underlay paths. The metrics that are mentioned as examples belong to the IP metrics category (throughput, delay, loss, jitter). Mentioning the IPPM framework and even the relevant RFCs would have helped, especially as there is a need for standard and stable definitions and methods of measurement in order to allow for an exchange of information between layers.
Agreed. I suggest adding a reference to RFC2330 in the last sentence of section 4.2.6:

 "such as defined in [RFC2330]."

Yes, this is useful.


'Performance' is mentioned a few more times in the document, with no reference to performance metrics. For example in section 3.3 there is talk about 'adequate performance to VM applications'.  It is not clear what this exactly means - what are the metrics for measuring performance of VM applications and how are they determined as 'adequate' (or not).

Would "the expected Quality of Service" instead of "adequate performance" be acceptable?

A further reference to RFC6390 could also be provided.



QoS is better than performance. The reference to 6390 is not necessary IMO, but maybe it would help to clarify that 'adequate QoS' means in the context of services measuring the performance parameters and making sure that they are within the limits defined by the SLA specific to the service.



In the other instances, the word 'performance"  is used in its general meaning.



Clarifying these issues would be very useful IMO, because the overall functionality of the overlays networks depends among other on the sufficient allocation of resources in the underlays. The metrics and methods of measuring performance need to be clearly articulated for this purpose.



Regards,



Dan