Re: [alto] new individual document notification

["Songhaibin (A)" <[e-mail]>]

Hi Michael,

Thank you for the feedback.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Scharf,
> Michael (Michael)
> Sent: Saturday, March 02, 2013 5:28 AM
> To: Enrico Marocco
> Cc: [e-mail]
> Subject: Re: [alto] new individual document notification
> 
> Hi Enrico, all,
> 
> I fully agree that the relationship between I2RS and ALTO requires careful
> thinking, because possibly guidance to the I2RS WG is needed. This is a timely
> topic, and I thank the authors of draft-song-alto-i2rs to bring this to the attention
> of the working group.
> 
> However, I wonder whether draft-song-alto-i2rs is a useful starting point for this
> discussion. Please find my concerns on the technical content below. I understand
> that this document is at an early stage, but in my opinion it is still not heading in
> the right direction.
> 
> 
> Title, Abstract, Introduction, and Terminology
> ----------------------------------------------
> 
> The title, abstract, and the introduction are fairly generic. While the acronym I2RS
> is never expanded in the text, and any reference is missing, I assume here that
> the new I2RS working group is implied implicitly. As far as I understand the
> planned work in I2RS, this new IETF working group discusses specific interactions
> with the Internet routing system. Apart from a short text in Section 4,
> draft-song-alto-i2rs-01 does not discuss I2RS specifically.

This draft was initially prepared for I2RS working group, to introduce ALTO scenarios and requirements for the underlying network information. There is an assumption that I2RS guys are familiar with I2RS. So it is not a surprise that there is not sufficient content about it. 


> Section 3.1
> -----------
> 
> The following section seems interesting, but I fail to see an actual contribution:
> 
>    An ALTO server needs the following information as input:
> 
>    o The network segments information.  Every access router manages one
>    or more IP address pools, to be assigned to the users through DHCP or
>    other ways."
> 
> What is the difference between "network segment information" and entries in
> "routing tables" (next bullet)? The IP address pools will have to used in routing as
> well. 

I have not carefully thought of it. But it could be easier for PID assignments with the direct IP address pool information than analyzing from the routing tables?

>Does the document suggest an interface between I2RS and a RADIUS server?

There could be.

> That would probably have to be discussed in the I2RS WG, I don't know if this is
> foreseen there.
> 
>    o The IP addresses of the interfaces of routers, and the routing
>    table information(IGP or BGP).  This o information can help to
>    construct the whole network topology.
> 
> Yes, but I2RS is not needed for that. See for instance draft-ietf-idr-ls-distribution.
> 

Thank you for the good pointer. 

> Also, note that an ALTO server almost certainly does not want to expose IP
> addresses of routers or router interfaces, as explained e. g. in
> draft-scharf-alto-vpn-service-00.

Right. I do not say ALTO server exposes this information to applications. But ALTO server may collect this information.

>    o The congestion status of the router interfaces, but this
>    information could be reflected in the routing table change
> 
> I think it has always been consensus that ALTO will not expose short-term
> "congestion" status. From draft-ietf-alto-protocol-14: "Recall that while ALTO may
> convey dynamic network information, it is not intended to replace near-real-time
> congestion control protocols."

I do not think applications need short term congestion status from ALTO server either. But ALTO server may collect the congestion information from the network if the congestion has its regularity, so that e.g. ALTO can provide reliable advice for applications to avoid some links during the peak hour?

> 
> Under the assumption that congestion here implies "long-term" interface
> utilization, this text would have to distinguish whether it refers to the load on the
> interfaces to each individual residential user, on the Internet-facing interfaces,
> etc. The latter seems to be closer related to
> draft-amante-i2rs-topology-use-cases-00 than the former, but I might be wrong.
> Note that congestion status towards a residential user could depend on the
> traffic class (e. g., different congestion status for Internet access vs. IPTV) and
> many other parameters.

Since the access network is an aggregation network, ALTO may not be targeted to solve its resource candidates selection issues. ALTO should focus on the latter.

> 
>    o Policy information, for example, one multi-homing AS prefers to use
>    which AS to transit its traffic, including the pricing information.
> 
> Agreed on the first points, this is what I2RS seems to be all about. I am curious
> how to retrieve pricing information from the routing system.
>

If we consider the system concept also includes the billing components for the routing.

> 
> Section 3.2
> -----------
> 
> This section is closely related to draft-lee-alto-ext-dc-resource. I don't see how
> that whole section matters to I2RS or ALTO. More specifically:
> 
>    The ALTO server needs to collect the following information so as to
>    provide this kind of service.
> 
>    o All switches' network capacity information
> 
> Unless I miss something, I2RS addresses routers, not switches.

I agree that this section may not be related to the routing system, or I2RS but a data center's network. If ALTO could be extended to provide the services inside a data center's network, to provide deployment position suggestions, these information may be needed. I am not sure if I2RS will or not target at data center network in the future. Same for the following questions.

>
>    o All physical servers' information(CPU, memory) in the data center
> 
> And this will be retrieved from the Internet routing system? How?


> 
>    o The storage space information in the data center
> 
> Same here?
> 
>    o The physical links information
> 
> Inside the data center one often has L2/Ethernet connectivity, i.e., no routing
> system. Apart from that detail, what link information specifically?
> 
>    o The virtual machines' information(CPU, memory) and its affinity
> 
> Same as above.
> 
>    o Pricing models
> 
> Again, I don't see the relation to I2RS for that.
> 
>    Based on the previous informaiton, ALTO server can provide the load
>    balancing/traffic optimization informaiton to ALTO client for data
>    centers, through map or ranking.
> 
> In summary, this list is to a large extend not about networking, and unrelated to
> I2RS, as far as I understand it. What do I miss?
> 
> 
> Section 4
> ---------
> 
>    So there could be two ways to go forward.
> 
>    (1) Defining a new protocol for all the functions(configuration and
>    disclosure) required by I2RS.  This protocol covers ALTO's south
>    bound information requirements on network topology, with its one
>    component.  But this protocol will be tremendously complicated.  It
>    will be related and overlapped with many existing protocols, such
>    like NetConf and YANG.
> 
> This seems to discuss protocols that I2RS may develop at some point in time. And
> the authors seem to believe that a future I2RS solution will be sufficient for ALTO.
> This is hypothetical, and it will depend on the ALTO use case.

This is for open discussion. Not a proposed way forward from the authors. And the community will finally find a appropriate way to solve these issues.

> 
> But if the assumption is right, it will not require any short-term action of ALTO.
> Not doing anything is certainly a realistic option for ALTO. But this also implies that
> this document is not required.
> 
>    (2) Defining the south bound interface for ALTO, to collect the
>    infrastructure information, and bring the requirements discussion in
>    I2RS, and identify the final scope, to avoid the overlap between
>    different WGs(ALTO, NetConf, NetMod).  The protocol development will
>    go to ALTO.
> 
> I strongly disagree that ALTO should develop a protocol to "collect the
> infrastructure information". This would fully overlap with other IETF work like
> draft-ietf-idr-ls-distribution and other solutions, and with a high probability also
> with whatever I2RS may work on. Therefore, this is no solution.

I do not think it would "fully" overlap with other IETF work, there is something ALTO concerns but other IETF work does not concern.
>
> I think that it could be worthwile to discuss in ALTO a third way:
> 
>    (3) Document the specific ALTO requirements for narrow-focused,
> well-known ALTO use-cases, e. g., in an information model, and provide those
> requirements to the I2RS WG. No protocol development will be needed in ALTO.
>
To distinguish from option (1), the protocols will not all defined in I2RS WG. If those protocols are developed in different places, and meet the ALTO requirements, then ALTO needs an informational guidance document to make them together.

> This would have to be a very detailed requirement analysis of what information is
> needed by ALTO, where the corresponding data is typically present in the
> Internet routing system, how it can be retrieved in a given ALTO use case, and
> what gaps may exist in current technologies. This may require substantial amount
> of work in the ALTO WG beyond generic hand-waving. For instance, it would
> require agreement on use cases, deployment scenarios of ALTO, how network
> and cost maps are compiled, etc. 


Agreed.

Thanks,
-Haibin



>I have doubts whether there is enough energy
> on that.

> 
> In summary, this is a relevant topic, but I believe that there are other,
> lower-hanging fruits for new work items in ALTO.
> 
> Thanks
> 
> Michael
> 
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Enrico Marocco
> > Sent: Wednesday, February 20, 2013 10:03 AM
> > To: [e-mail]
> > Subject: Re: [alto] new individual document notification
> >
> > I believe this effort is very useful. The i2rs WG is in fact
> > considering the ALTO protocol as a candidate for some of the
> > use cases they are focusing on (see e.g.
> > http://tools.ietf.org/html/draft-amante-i2rs-topology-use-case
> > s-00#section-4.3).
> > The more information ALTO experts can provide to help them
> > make an informed decision, the better. I would encourage
> > anyone who have been involved in the development of the ALTO
> > protocol to coordinate with Haibin and Young, and help people
> > outside the WG understand whether the work done here could be
> > a good match for their needs.
> >
> > Enrico
> >
> > On 2/19/13 4:17 AM, Songhaibin (A) wrote:
> > > Hi all,
> > >
> > >
> > >
> > > We have submitted a new individual document.
> > >
> > > http://tools.ietf.org/html/draft-song-alto-i2rs-00
> > >
> > >
> > >
> > > Which is aimed to focus on gathering infrastructure information for
> > > ALTO service. I think it could be called the south bound
> > interface for ALTO.
> > > This document is also related to i2rs wg. Anybody who has the same
> > > interest to contribute is welcome to join us, we plan to give an
> > > update by next Monday.
> > >
> > >
> > >
> > > Regards!
> > >
> > > -Haibin
> > >
> > >
> > >
> >
> >
> >
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto