Hi Sabine, Thanks again for your further comment. Please see in-line for my response.
Best Regards, Young -----Original Message----- From: Sabine Randriamasy [mailto:[email protected]] Sent: Tuesday, July 31, 2012 1:05 PM To: Leeyoung Cc: [email protected] Subject: Re: [altoext] FW: New Version Notification for draft-lee-alto-app-net-info-exchange-00.txt Hi Young, Thanks a lot for your answers. Please see some more comments inline. Again with now the ALTO list in Cc Best regards Sabine Leeyoung a écrit : > Hi Sabine, > > Here's my response to your comments to your detail questions. Please see > in-line. > Sreekants or Greg may be able to provide more comments later. > > Thanks, > Young > > -----Original Message----- > From: Sabine Randriamasy [mailto:[email protected]] > Sent: Monday, July 30, 2012 12:14 PM > To: Leeyoung > Cc: [email protected] > Subject: Re: [altoext] FW: New Version Notification for > draft-lee-alto-app-net-info-exchange-00.txt > > 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. > > YOUNG>> Thanks. Agreed. We may define a new cost attribute (TBD the name). > > - '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) > > YOUNG>> In the encoding example we gave in the draft, we used the constraints > Convention such as 'lt, gt, eq, ...' Please see Section 3.5. > Ok. Then it may help if the text in §3.1 is reflecting such an expression of constraints. YOUNG>> Yes we will add explanation text in Section 3.1 on these constraints convention. > > - what kind of information is member 'Parameters' is supposed to carry > and for what use? > > YOUNG>> We put it as a place holder for indicating values of the resulting > graph or link > representation of network abstraction, but in the actually encoding example, > we simply used > what is defined in DstCostsConstraints Object (such as pktloss, etc.) to > indicate the vaules > associated with the S-D path. We can delete it if this is not necessary. > Or maybe clarify the definition. YOUNG>> Yes. Will provide. > > - 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 > > YOUNG>> Good observation. We put them as a place holder for future > enhancement. > > ++ 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. > > YOUNG>> We did not mean not leaving it out. See Section 3.5 example if that > satisfies your question. > Ok, then adding the *value* to "cost type" would fully clarify YOUNG>> OK. > > - '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). > > YOUNG>> Yes. Agree. > > - how is the 'Administration Domain ID' of a S-D pair reported and why > is it needed? > > YOUNG>> Sorry for poor writing. We didn't mean this Admin Domain ID of a S-D > pair. We actually meant here ALTO client may collect network resource > information from different network domains in case of the multi-domain > scenario. > ok > ++ 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. > > YOUNG>> Agreed. We will indicate what is new in the revision. > > - 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. > > YOUNG>> Yes, we will make it clear. > Ok > > - 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"? > > YOUNG>> We may have a case in which to specify more than 1 src EP. The > example is > Simply an example with only 1 src EP. We have other examples where multiple > sources may need to be specified. > Ok. Then why not keeping "EndpointFilter"? YOUNG>> > ++ Section 3.4 Information Model of ALTO Response ... > - object CsoInfoResourceEndpointCostMap has the same structure than > InfoResourceEndpointCostMap of base protocol > > YOUNG>> Yes, we did not mean to invent new object. > Ok. I guess a later version with updated information models and examples will clarify this as well. YOUNG>> Will clarify this in the revision. > - 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. > > YOUNG>> Actually it refers to constraint values. I tend to agree with you. > > - why is this set of cost types already set at this level of > specification? > > YOUNG>> I don't understand this question. > I meant the list of cost types used in the constraints could be more generic. YOUNG>> Let's discuss this point face-to-face. > ++ 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. > > YOUNG>> Yes, we should have referred to your multi-cost draft properly. We > did not mean to propose a new thing with respect to multi-cost. We will clean > up what is new and what is referenced in the revision. > Ok. > > ++ Section 4.1 Representing.... > - this section is rather about representing links and their attributes, > so could be named accordingly > > YOUNG>> We discussed this aspect previously. Do you have a good suggestion of > Naming? > How about something like "Representing links and their attributes" ? YOUNG>> This sounds good to me. > > - the graph specification is curretnly a list of links, do you intend to > extend so that one can infer its structure? > > YOUNG>> Please look at draft-bernstein-alto-large-bandwidth-cases-02.txt for > Further enhancement from this. We want to represent some path vector only > with shared links and the link cost of those shared links so that some level > of structure may be inferred by Application stratum. > Ok. > > - is there a reason preventing member 'r-cap' to be specified as > JSONNumber capacity? > > YOUNG>> I think we can. But I defer this question to Greg. > > - what is the usage of wt at this level of a spec ? (could also be > 'JSONNumber weight') > > YOUNG>> Weight is similar to routing 'cost' notion of OSPF or other link cost > that operators use for non-TE link cost. > I was mislead by the name 'wt' (sorry forgot the expression in the other draft). YOUNG>> OK > 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: [email protected] [mailto:[email protected]] >> Sent: Monday, July 09, 2012 11:06 AM >> To: Leeyoung >> Cc: [email protected]; Sreekanth madhavan; [email protected]; >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/altoext >> >> > > _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
