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

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 02 Jul 2012 11:41:29 +0800

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. 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. 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? A curious question, does the ALTO servers
(as well as the SC) in H form some kind of mesh (peering) among themselves?

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

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: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, June 28, 2012 3:07 PM
> To: Haiyong Xie
> Cc: [email-masked]; 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Haiyong Xie <[email-masked]>
Date: Mon, 2 Jul 2012 10:50:51 -0700

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:
> 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
> 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
> given the "early-stageness" of SDN. A related general comment is that
> it maybe quite
> 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

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

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.

>> 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.
>>
>> Subject: New Version Notification for
>> draft-xie-alto-sdn-extension-use-cases-00.txt
>>
>>
>> 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:
> .

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 04 Jul 2012 18:17:25 +0800

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

>> controlled domain. ALTO currently does not define how its information is

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

> When we update the draft, we will add them to the figures.
sounds good.

---

From: Haiyong Xie <[email-masked]>
Date: Fri, 6 Jul 2012 10:03:53 -0700

Hi Richard,

Please see my inline comments.

On 07/04/2012 03:17 AM, Y. Richard Yang wrote:
> ...

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

>>> ......

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.

>> ......
Agreed.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 27 Jul 2012 11:01:04 +0000

Hi,

Now that I have had time to re-read this thread and go through the documents,
the comments and the slides we are preparing for our next meeting in
Vancouver, I have come to a couple of conclusions I want to share with you.

The first of all is that we'd probably have to change the title. Both
the contents and the discussions around are more related to architecture
than to anything else. What if we change it into something like "Architecture
for ALTO and SDN interoperation"

The second is related to the conditions for "network partition" (that I
prefer to call "subnetwork interconnection" or "federation", if you like)
in the H architecture. Hayiyong put two conditions:

> (2) m ALTO servers could work jointly (e.g., by forming mesh/peering

And somehow implies they are both necessary. I think federation could be
achieved as long as just one of them is provided. In the first case, each
AS would learn data from the integrated view of its corresponding SC. In
the second case, SCs would know about other domains through what their
associated ASes have received.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx