Subject: Re: [alto] [altoext] FW: New Version Notification for draft-lee-alto-app-net-info-exchange-00.txt

From: Sabine Randriamasy <[email-masked]>
Date: Wed, 1 Aug 2012 11:13:00 +0200

Hi Young,

Thanks for your answers. As for the discussions on the cost types used 
in constraints, it will have to be per e-mail as I am not attending IETF 
this time.
Best regards
Sabine

Leeyoung a écrit :
> 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-masked]] 
> Sent: Tuesday, July 31, 2012 1:05 PM
> To: Leeyoung
> Cc: [email-masked]
> 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-masked]] 
>> Sent: Monday, July 30, 2012 12:14 PM
>> To: Leeyoung
>> Cc: [email-masked]
>> 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-masked] [mailto:[email-masked]] 
>>> Sent: Monday, July 09, 2012 11:06 AM
>>> To: Leeyoung
>>> Cc: [email-masked]; Sreekanth madhavan; [email-masked]; 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-masked]
>>> https://www.ietf.org/mailman/listinfo/altoext
>>>   
>>>     
>>>       
>>   
>>     
>
>   

-- 

---------------------------------------------------------
Sabine RANDRIAMASY 
Alcatel-Lucent Bell Labs France 
Centre de Villarceau
Route de Villejust - 91620 NOZAY - FRANCE

E-MAIL : [email-masked]
TEL: +33 (0)1 30 77 27 45 
         (On Net) 2 103 27 45
---------------------------------------------------------

---

From: sreekanth madhavan <[email-masked]>
Date: Wed, 1 Aug 2012 15:56:05 +0530

Hi Sabine,

Thanks for providing the comments.

My response for some of the comments , even though Young has already
clarified most of them.

- 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. 

----[sreekanth]: We will be extending the Cost-Type and would like to keep
the Cost-Mode as Summary and Gragh.

- 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. 

----[sreekanth]: Alto response:

   object {
               JSONNumber hopcount;
         JSONNumber latency;
         JSONNumber pktloss;
   } DstCostsConstraints;

   object EndpointDstCosts {
        DstCostsConstraints[TypedEndpointAddr];     ...
      };
      object {
        EndpointDstCosts [TypedEndpointAddr]<0..*>;
        ...
      } EndpointCostMapData;
      object {
        CostMode            cost-mode;
        CostType            cost-type;
        EndpointCostMapData map;
      } CsoInfoResourceEndpointCostMap;

For each Source Endpoint, a EndpointDstCosts object denotes the associated
"cost + constraints" to each
Destination Endpoint specified in the input parameters; the name for each
member in the object is the TypedEndpointAddr string identifying the
corresponding Destination Endpoint. This can be viewed as a two dimensional
array which holds cost + constraints value.

We extended the EndpointDstCosts by adding constraints value and hence
cannot reuse the EndpointDstCosts (which is wrong in the current
draft)object defined by base. The same is the case for
InfoResourceEndpointCostMap object of the base.

- why is this set of cost types already set at this level of specification?

----[sreekanth]: Could you please clarify this point ?

Regards,
Sreekanth

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Sabine Randriamasy
Sent: Tuesday, July 31, 2012 10:51 PM
To: Leeyoung
Cc: [email-masked]
Subject: Re: [alto] [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.
> Subject: Re: [altoext] FW: New Version Notification for
draft-lee-alto-app-net-info-exchange-00.txt
> 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 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.  
> I will provide the responses to your detail questions later. 
> Thanks. 
>
> Young
>
>
>
>          
>
> Thanks,
> Sabine
>
>> We have just published ALTO extension to support application and network
resource information exchange for high bandwidth applications.
>> Subject: New Version Notification for
draft-lee-alto-app-net-info-exchange-00.txt
>> Title:		 ALTO Extensions to Support Application and Network
Resource Information Exchange for High Bandwidth Applications
>> 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

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto