Re: [altoext] FW: New Version Notification for draft-lee-alto-app-net-info-exchange-00.txt
Sabine Randriamasy <Sabine.Randriamasy@alcatel-lucent.com> Mon, 30 July 2012 17:14 UTC
Return-Path: <sabine.randriamasy@alcatel-lucent.com>
X-Original-To: altoext@ietfa.amsl.com
Delivered-To: altoext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5292811E80A3 for <altoext@ietfa.amsl.com>; Mon, 30 Jul 2012 10:14:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.482
X-Spam-Level:
X-Spam-Status: No, score=-9.482 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cffLWoHvV0gw for <altoext@ietfa.amsl.com>; Mon, 30 Jul 2012 10:14:23 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1D21F8587 for <altoext@ietf.org>; Mon, 30 Jul 2012 10:14:22 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6UHEFcn028853 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 30 Jul 2012 19:14:15 +0200
Received: from [172.27.204.117] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 30 Jul 2012 19:14:15 +0200
Message-ID: <5016C0DD.8050909@alcatel-lucent.com>
Date: Mon, 30 Jul 2012 19:14:05 +0200
From: Sabine Randriamasy <Sabine.Randriamasy@alcatel-lucent.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Leeyoung <leeyoung@huawei.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1720CC2D35@dfweml511-mbx.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1720CC2D35@dfweml511-mbx.china.huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Cc: "altoext@ietf.org" <altoext@ietf.org>
Subject: Re: [altoext] FW: New Version Notification for draft-lee-alto-app-net-info-exchange-00.txt
X-BeenThere: altoext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Non-WG list for discussions related to ALTO Protocol Extensions <altoext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/altoext>, <mailto:altoext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/altoext>
List-Post: <mailto:altoext@ietf.org>
List-Help: <mailto:altoext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/altoext>, <mailto:altoext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jul 2012 17:14:24 -0000
Hi Young, I have read your draft and have a couple of comments and questions. In Section 2 Problem statement, I agree with the need to reduce the amount of conveyed ALTO information through topology filtering and constraint-based response filtering. The ALTO base protocol specifies these features for the Cost Map, Filtered cost map and Endpoint cost services. I also agree with the necessity to provide several types of cost information which stresses the necessity of extended filtering mechanisms. In the Constraints filtering extensions of Section 3, I didnt' really get how information confidentiality is preserved and the proposed specification raised the questions detailed below. I also agree that detailing end to end path costs at the link level at some places can be beneficial, especially for local bottlenecks sometimes with fast changing cost values. Figure 2 shows an example with Link capacity costs but section 2 uses them rather as capacity, where I figure the higher the better. Without a hint on how path costs are calculated it is hard to follow the rationale on the DC choice by ER1. See also the questions detailed below. Thanks, Sabine ------------------------- Detailed questions ----------------------------- ++ Section 3.1 ALTO Query from Application Stratum to Network Stratum Names used in the list of requested information may be misleading: - A 'Cost Type' see base protocol (§5.1.1) is expected to indicate an attribute that has a value such as number, boolean, string... and is is rather "semantic". 'summary' and 'graph' are cost attributes of different nature. - 'Constraints' such as 'min/max metric' look like objectives rather than expressions such as 'lt. value' as specified in the base protocol (§ 6.8.2.2.3) - what kind of information is member 'Parameters' is supposed to carry and for what use? - Some members listed here do not appear in the ALTO Query Information Model of §3.3: 'parameters' 'objective-function'. Neither do they appear in the example of §3.5 ++ Section 3.2 ALTO response from Network .... - The list of S-D pairs should carry the Cost Type *values* as the supported Cost Types are expected to be listed and checked in the IRD. - 'Constraint values': need to be clarified: is it the actual cost value? then the draft should specifiy that the constraits relate to Cost Types (as defined in §5.1.1). - how is the 'Administration Domain ID' of a S-D pair reported and why is it needed? ++ Section 3.3 Information Model of ALTO Query ... Looking at the specification here, it is hard to figure out what is really extended here w.r.t. the Endpoint Cost Service query input specified in the base protocol. - A new media type "CsoReqEndpointCostMap" and differs from "ReqEndpointCostMap" of the base protocol in that the set in member 'contraints' is encoded/interpreted differently, according to example in §3.5. Then a different member name than 'contraints' should be used. - As for member 'endpoints': unless you need to specify only 1 src EP, what is the need to define a new object "EndpointFilterExt" instead of keeping the "EndpointFilter"? ++ Section 3.4 Information Model of ALTO Response ... - object CsoInfoResourceEndpointCostMap has the same structure than InfoResourceEndpointCostMap of base protocol - what in the list of §3.2 does object 'DstCostsConstraints' refer to? - this object seem to be encoded like a set of JSONNumbers that are the values of resp. hopcount, latency and packet loss. So I guess, they should be arranged in an array. - why is this set of cost types already set at this level of specification? ++ Section 3.5 ALTO protocol extension... I agree with the idea of providing several Cost Type values at a time but the encoding could be lighter. The draft "Multi-Cost ALTO" proposes one example. There is a real need that this section be harmonized with the previous specification sections, as the encoding provided in the examples are misleading. ++ Section 4.1 Representing.... - this section is rather about representing links and their attributes, so could be named accordingly - the graph specification is curretnly a list of links, do you intend to extend so that one can infer its structure? - is there a reason preventing member 'r-cap' to be specified as JSONNumber capacity? - what is the usage of wt at this level of a spec ? (could also be 'JSONNumber weight') Leeyoung a écrit : > Hi All, > > We have just published ALTO extension to support application and network resource information exchange for high bandwidth applications. > This is part of the i2aex initiative. > > Thanks in advance for your comment and discussion. > > Young > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 09, 2012 11:06 AM > To: Leeyoung > Cc: choits@etri.re.kr; Sreekanth madhavan; gregb@grotto-networking.com; Dhruv Dhody > Subject: New Version Notification for draft-lee-alto-app-net-info-exchange-00.txt > > > A new version of I-D, draft-lee-alto-app-net-info-exchange-00.txt > has been successfully submitted by Young Lee and posted to the > IETF repository. > > Filename: draft-lee-alto-app-net-info-exchange > Revision: 00 > Title: ALTO Extensions to Support Application and Network Resource Information Exchange for High Bandwidth Applications > Creation date: 2012-07-09 > WG ID: Individual Submission > Number of pages: 14 > URL: http://www.ietf.org/internet-drafts/draft-lee-alto-app-net-info-exchange-00.txt > Status: http://datatracker.ietf.org/doc/draft-lee-alto-app-net-info-exchange > Htmlized: http://tools.ietf.org/html/draft-lee-alto-app-net-info-exchange-00 > > > Abstract: > This draft proposes ALTO information model and protocol extensions to > support application and network resource information exchange for high > bandwidth applications in partially controlled and controlled > environments as part of the infrastructure to application information > exposure (i2aex) initiative. > > > > > > > The IETF Secretariat > _______________________________________________ > altoext mailing list > altoext@ietf.org > https://www.ietf.org/mailman/listinfo/altoext >
- [altoext] FW: New Version Notification for draft-… Leeyoung
- Re: [altoext] FW: New Version Notification for dr… Martin Stiemerling
- Re: [altoext] FW: New Version Notification for dr… Sabine Randriamasy
- Re: [altoext] FW: New Version Notification for dr… Leeyoung
- Re: [altoext] FW: New Version Notification for dr… Leeyoung