Re: [alto] FW: New Version Notification for draft-xie-alto-sdn-extension-use-cases-00.txt
"Y. Richard Yang" <yry@cs.yale.edu> Wed, 04 July 2012 10:17 UTC
Return-Path: <yry@cs.yale.edu>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D39821F87A8; Wed, 4 Jul 2012 03:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0DP3bQDqZq5; Wed, 4 Jul 2012 03:17:30 -0700 (PDT)
Received: from vm-emlprdomr-06.its.yale.edu (vm-emlprdomr-06.its.yale.edu [130.132.50.147]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71121F87A3; Wed, 4 Jul 2012 03:17:30 -0700 (PDT)
Received: from [192.168.1.108] ([221.221.23.217]) (authenticated bits=0) by vm-emlprdomr-06.its.yale.edu (8.14.4/8.14.4) with ESMTP id q64AHR0P006445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jul 2012 06:17:29 -0400
Message-ID: <4FF41835.5020002@cs.yale.edu>
Date: Wed, 04 Jul 2012 18:17:25 +0800
From: "Y. Richard Yang" <yry@cs.yale.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Haiyong Xie <haiyong.xie@huawei.com>
References: <748A482AA35F7A4A8BD26465029B8C4A1B7C49EC@dfweml509-mbx.china.huawei.com> <4FF11869.1010408@cs.yale.edu> <4FF1DF7B.9080500@huawei.com>
In-Reply-To: <4FF1DF7B.9080500@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.71 on 130.132.50.147
Cc: "altoext@ietf.org" <altoext@ietf.org>, "alto@ietf.org" <alto@ietf.org>, Andreas Voellmy <andreas.voellmy@yale.edu>, Hongtao Yin <hongtao.yin@huawei.com>
Subject: Re: [alto] FW: New Version Notification for draft-xie-alto-sdn-extension-use-cases-00.txt
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2012 10:17:32 -0000
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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Thursday, June 28, 2012 3:07 PM >>> To: Haiyong Xie >>> Cc: diego@tid.es; 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 >>> alto@ietf.org >>> https://www.ietf.org/mailman/listinfo/alto >> . >>
- [alto] FW: New Version Notification for draft-xie… Haiyong Xie
- Re: [alto] FW: New Version Notification for draft… Y. Richard Yang
- Re: [alto] FW: New Version Notification for draft… Haiyong Xie
- Re: [alto] FW: New Version Notification for draft… Y. Richard Yang
- Re: [alto] FW: New Version Notification for draft… Haiyong Xie
- Re: [alto] New Version Notification for draft-xie… Diego R. Lopez