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

From: Leeyoung <[email-masked]>
Date: Mon, 9 Jul 2012 16:10:06 +0000

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

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 12 Jul 2012 22:07:43 +0200

A gentle reminder to avoid cross-posting to several mailing list.

Thank you,

   Martin

On 07/09/2012 06:10 PM, Leeyoung wrote:
> _______________________________________________
> altoext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/altoext
>

-- 
[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited
Registered Office: NEC House, 1 Victoria Road, London W3 6BL
Registered in England 283

---

From: Sabine Randriamasy <[email-masked]>
Date: Mon, 30 Jul 2012 19:14:05 +0200

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')

---

From: Leeyoung <[email-masked]>
Date: Mon, 30 Jul 2012 18:00:02 +0000

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

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. 

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 will provide the responses to your detail questions later. 
Thanks. 

Young

Thanks,
Sabine

---

From: Leeyoung <[email-masked]>
Date: Mon, 30 Jul 2012 23:30:12 +0000

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,

Thanks,
Sabine

------------------------- Detailed questions -----------------------------

YOUNG>> Thanks. Agreed. We may define a new cost attribute (TBD the name).

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.

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. 

YOUNG>> Good observation. We put them as a place holder for future enhancement. 

YOUNG>> We did not mean not leaving it out. See Section 3.5 example if that satisfies your question. 

YOUNG>> Yes. Agree. 

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. 

YOUNG>> Agreed. We will indicate what is new in the revision.

YOUNG>> Yes, we will make it clear. 

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. 

YOUNG>> Yes, we did not mean to invent new object.

YOUNG>> Actually it refers to constraint values. I tend to agree with you. 

YOUNG>> I don't understand this question. 

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. 

YOUNG>> We discussed this aspect previously. Do you have a good suggestion of
Naming? 

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.

YOUNG>> I think we can. But I defer this question to Greg.

YOUNG>> Weight is similar to routing 'cost' notion of OSPF or other link cost that operators use for non-TE link cost.