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

[Haiyong Xie <[e-mail]>]

Hi Richard,

Please see my inline comments.

On 07/04/2012 03:17 AM, Y. Richard Yang wrote:
> ...
>> 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?

H could allow network partition provided that the following two
conditions are satisfied:
(1) m SCs can form a mesh/peering to work together
(2) m ALTO servers could work jointly (e.g., by forming mesh/peering
among themselves).

Currently, we have a draft draft-yin-sdn-sdni-00.txt (
http://www.ietf.org/id/draft-yin-sdn-sdni-00.txt ) dedicated to
condition (1), and this draft hopeful could provide a starting point for
solving the SC mesh/peering problem. However, we are not aware of any
draft that solves condition (2). If you know any such work that could be
leveraged to solve (2), please kindly let us know.

Given the current status, we think that it is difficult (or too early)
to do network partition in the H architecture. However, if both of the
above two conditions are satisfied, I believe network partitioning is
feasible in the H architecture.

Regarding inter-ALTO, we think that although it is doable, but we do not
see convincing use cases yet; we compared the need for inter-SDN-domain
and inter-ALTO, and think that inter-SDN-domain has more convincing uses
cases (see our draft draft-yin-sdn-sdni-00).

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

Agreed. Our viewpoint is that since SC architecture and standard are not
settled yet (they are still evolving), we'd better not rush into the
approach of integrating SC and ALTO; instead, separating them is a
safer, more flexible and economic approach.

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