Hi Sabine, Thanks for your further comments. Please see in-line for my response.
Best Regards, Young -----Original Message----- From: Sabine Randriamasy [mailto:[email protected]] Sent: Tuesday, July 31, 2012 12:21 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 for your answers. Please see inline for further comments. I have put the "alto" list in Cc rather than "altoext" which will be closed. Best regards Sabine Leeyoung a écrit : > Hi Sabine, > > Thanks for providing your comments to our drafts. Please see in-line for my > response. > > Best Regards, > 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. > > YOUNG>> Information confidentiality is a big issue which the current draft > has not addressed yet. The current draft was written in the "controlled" or > "partially controlled" environments which means there is a trusted > relationship amongst the entities involving the exchanges of resource data. > In generic framework where there may be no such trusted relationship amongst > the entities, we need to address such issue down the road. > Ok. Indeed, ALTO environment control is introduced in the Introduction. I was mislead by seing "Such information may be considered sensitive to the network provider just as..." just before "Section 3 provides ALTO information model and protocol extensions to support... " YOUNG>> We will clarify this. > 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. > > YOUNG>> We actually enhanced this mechanism in section 6 of > draft-bernstein-alto-large-bandwidth-cases-02.txt > where we include path vector along with link b/w. Path vector indicates > shared link information from which > The bottle neck link can be identified. > > For instance, consider the following example from the draft. > > > +----+ L0 Wt=10,BW=50 +----+ > | N0 |-----------------------------------------| N3 | > +----+ `. +----+ > | `. L4 Wt=7 | > | `-. BW=40 | > | `. +----+ | > | `.| N4 | | > | L1 .' +----+ | > | Wt=10 / L2 | > | BW=45 / Wt=12 | > | /L5 Wt=10 BW=30 | > | .' BW=45 | > | / | > | / | > +----+ .' L3 Wt=15 BW=42 +----+ > | N1 |.........................................| N2 | > +----+ +----+ > > Now suppose the network of Figure 1 is a TDM network controlled by > GMPLS. Once again N0 representing a large data center and nodes N2 > and N3 as potential clients. However in this case the network provider > offers an additional path, P3, for getting from N0-N2. > > Path Src-Dest Path Vector Path Cost > > P1 N0-N2 {L0, L2} 22 > P2 N0-N3 {L0} 10 > P3 N0-N2 {L1,L3} 25 > ---------------------------------- > Link Bandwidth > L0 50 > L1 45 > L2 30 > L3 42 > > So the draft now propose that the network can provide abstract path > list along with link bottlenecks. We also provide how this mechanism > works for IP and other types of networks. > I'm fine with the rationale in draft-bernstein-alto-large-bandwidth-cases-02.txt. It's just that in draft-lee-alto-app-net-info-exchange-00.txt I missed the relation between the "LinkCapacity Cost" & ALTO Cost Map in Figure 2 and also the explanatory text text. Maybe a little clarifying edition can help. YOUNG>> Yes, we will clarify in the revision. We did not have time to synchronize between uses-case 01 and 02. > I will provide the responses to your detail questions later. > Thanks. > > Young > > > > > > 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: [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
