Re: [alto] FW: New Version Notification for draft-xie-alto-sdn-extension-use-cases-00.txt

[Haiyong Xie <[e-mail]>]

Hi Richard,

Thanks very much for your comments. Please see my inline responses below.

On 07/01/2012 08:41 PM, Y. Richard Yang wrote:
> Hi Haiyong, Tina, Hongtao, and Diego,
>
> A good document! Here are some quick feedback:
>
> - One take-away message that the document appears trying to convey is
> Vertical (V) vs Horizontal (H) architectures. My understanding of your
> definition
> is that V is a one-to-many setting, i.e., one ALTO Server to m SDN
> Controllers (SC),
> while H is one-to-one, i.e., one ALTO Server to one SC. 

The H architecture implies that the network should NOT be segmented,
i.e., there exists only one SC; otherwise, the network will have
multiple ALTO servers, each is working with corresponding SC only, but
without exchanging information among multiple ALTO servers (we do not
have a protocol to do so yet).

> Why is the information flow
> in H only SC <- ALTO S (Sec. 3.2), not the other way around? In an SDN
> setting, I
> agree that an SC should already collect fine-grained, dynamic
> information for its
> controlled domain. ALTO current does not define how its information is
> collected/provisioned, but SC provides a good source (Sec. 4.3.2) of
> information
> for ALTO Server to aggregate and conduct abstraction. I see good value
> in this
> direction of information flow. I feel that this is mostly a common
> problem across H
> and V. Hence I would not discard the H architecture right away. 

Adding SC->ALTO S in the H architecture does not add much new value.
Since the ALTO Server is working for the specific SDN domain only, the
more important of problem, i.e., how to coordinate multiple SCs in the
whole network, remains unsolved. Plus, in the H architecture, we really
do not have to differentiate ALTO S from SC, as the former could be
easily integrated into the latter (since SC has the most updated network
information already).

I agree that generally speaking, adding the SC->ALTO S information flow
is pretty helpful to ALTO, as this enables ALTO to collect network
information, which has not been addressed previously yet. However, we
believe that the main distinctions between the V and H architectures
include not only whether we have the SC->ALTO S flow, but also how we
should decompose the ALTO related functionalities and design an
efficient, evolvable architecture to support the growth of both SDN and
ALTO.

> A concern is
> whether we are ready to define the SC -> ALTO Server information flow,
> given the "early-stageness" of SDN. A related general comment is that
> it maybe quite
> helpful to extract common problems (e.g., unknown/dynamic network cost as
> you mentioned) and new possibilities for ALTO when introducing SDN,
> instead of
> a specific setting of a network being partitioned into many
> sub-networks in a V
> architecture. What do you think? 

Partitioning the network and defining common problems/possibilities of
SC->ALTO S information flow are two orthogonal problems. We believe that
both are equally important. However, the first problem (partitioning the
network) will largely determine what the SDN+ALTO architecture looks
like, while the second problem is more about the types of detailed
network information, its format, etc. From this perspective, it seems
that the first problem is more important -- if the architecture is not
set right at the beginning, to fix it at some later time would be
difficult and costly. This draft is mainly focusing on the first
problem, we may need another draft dedicated to the second problem.

> A curious question, does the ALTO servers
> (as well as the SC) in H form some kind of mesh (peering) among
> themselves?

Given current status of ALTO, we assumed that there is no peering among
ALTO servers. However, if ALTO server peering becomes available and
adopted, then the H architecture (and the SC->ALTO S flow) would make
much more sense, which allows us to compare the two architectures more
thoroughly.

>
> - The document seems to imply some kind of exclusive SC/net app
> setting: either
> SC or net app, but not both. Do I misunderstand it? This depends on
> how one
> define the scope of SC. There can still be net apps running. Does it
> make sense to
> include (explicitly) the net apps into your discussions/figures to
> include 4 types
> of entities: devices, SC, ALTO Server, and net apps? 

Actually we did not mean to imply any kind of exclusive SC/net app
setting. We need to update the draft to make it more explicit. In the
figures, we did not include the net apps for the sake of simplicity.
When we update the draft, we will add them to the figures.

> I like your distinction between
> SDN-aware and SDN-unaware apps. I am not sure I fully agree or
> understand your
> statement that SDN-aware apps would prefer direct communications with
> SC, but
> this will be an important architecture discussion at the ALTO meeting.

What we have in mind is that since some apps are SDN aware, then it may
prefer to behave differently from SDN unware apps (which does not
directly communicate with SC), i.e., directly communicate with SC, which
allows more flexibility and new possibilities of leveraging the SDN
capabilities. Apparently discussions would be very helpful, and I am
sure it would be a very interesting discussion about SDN-awareness and
-unawareness at the ALTO meeting.

>
> Thanks.
>
> Richard
>
> On 6/29/12 6:15 AM, Haiyong Xie wrote:
>> Hi All,
>>
>> This is a proposal on the interaction between ALTO and SDN we'd like
>> to discuss at our next meeting in Vancouver. This draft replaces the
>> older submission draft-xie-alto-sdn-use-cases-01.txt which was
>> withdrawn already.
>>
>> Comments or discussions are extremely welcome and appreciated.
>>
>> Best regards,
>> Haiyong
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Thursday, June 28, 2012 3:07 PM
>> To: Haiyong Xie
>> Cc: [e-mail]; Hongtao Yin; Tina TSOU
>> Subject: New Version Notification for
>> draft-xie-alto-sdn-extension-use-cases-00.txt
>>
>>
>> A new version of I-D, draft-xie-alto-sdn-extension-use-cases-00.txt
>> has been successfully submitted by Haiyong Xie and posted to the
>> IETF repository.
>>
>> Filename:     draft-xie-alto-sdn-extension-use-cases
>> Revision:     00
>> Title:         Use Cases for ALTO with Software Defined Networks
>> Creation date:     2012-06-28
>> WG ID:         Individual Submission
>> Number of pages: 28
>> URL:            
>> http://www.ietf.org/internet-drafts/draft-xie-alto-sdn-extension-use-cases-00.txt
>> Status:         
>> http://datatracker.ietf.org/doc/draft-xie-alto-sdn-extension-use-cases
>> Htmlized:       
>> http://tools.ietf.org/html/draft-xie-alto-sdn-extension-use-cases-00
>>
>>
>> Abstract:
>>     The introduction of SDN fundamentally changes the way that the ALTO
>>     works.  This draft describes the Vertical Architecture and the
>>     Horizontal Architecture allowing coherent coexistence of application
>>     layer traffic optimization (ALTO) with software defined network
>>     (SDN).  Unique requirements for design and operations are identified
>>     and summarized, suggesting that the Vertical Architecture allows
>>     better division, management, flexibility, privacy control and long-
>>     term evolution of the network.  We also define the main interactions
>>     and information flows, and present a set of use cases to illustrate
>>     how we extend ALTO to support SDN, in the Vertical Architecture.
>>
>>                                                                                   
>>
>>
>> The IETF Secretariat
>> _______________________________________________
>> alto mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/alto
>
> .
>