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

["Y. Richard Yang" <[e-mail]>]

On 7/3/12 1:50 AM, Haiyong Xie wrote:
> 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).
>
This is different from my understanding. I thought that H still could allow
network partition, say m sub-networks. Then there are m SCs and m ALTO
servers. The m SCs can form a mesh/peering to work together. Now I 
understand
your design. But how about the partitioned H design? Is it allowed? If 
there are
convincing use cases for inter-ALTO Server in your design, then it
identifies a need for inter-ALTO. What do you think?

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

 From a modular design's point view, an SC could be a multiple-functional
components, multiple-machines system (e.g., front end, policy server,
database server). Hence, although conceptually we could say that an ALTO
Server can be integrated into an SC, a more detailed may reveal more 
structures.
> 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.
>
Defining the first problem--partitioning the network clearly provides a
good use case and problem problem definition. This is a quite interesting
perspective.

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