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