Hi Qiao, Please see below.
On Saturday, March 21, 2015, Fu Qiao <[email protected]> wrote: > Hi, Richard. Thank you for your comments. I put some inlines as follows. > Looking forward to have more discussion with you. > > > > *发件人:* [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> [mailto: > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] *代表 *Y. Richard > Yang > *发送时间:* 2015年3月20日 21:27 > *收件人:* Qiao Fu > *抄送:* 邓灵莉/Lingli Deng; IETF ALTO; [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > *主题:* Re: [alto] 答复: New Version Notification for > draft-fu-alto-nfv-usecase-04.txt > > > > Dear Qiao, Lingli, > > Interesting discussions on an interesting problem. I liked your evaluation > on the impacts of NFV on ALTO. Here are a few comments. > > My reading of your draft is that the main impacts will be information flow > from NFV-MANO to the ALTO server; that is, NFV provides information to ALTO > server. The provisioning of ALTO servers is left as implementation details > so far, and I feel that we are coming to a point where more discussions can > be helpful. Your draft serves a great starting point. What is the mechanism > that you envision this information flow happens: (a) NFV writes (pushes) > into an internal (proprietary) data structure of ALTO server; (b) NFV > writes (pushes) into ALTO server using a standard (e.g., YANG comes to > mind); and/or (c) ALTO server pulls from NFV. From Section 6, you appear to > be suggesting that the ALTO server "subscribes" to NFV info updates (e.g., > the sentence "Such capability should be noticed...") Is there such a > standard interface in NFV? > > > > [fq] The north bound interface NFV now support could be Restful API. > Therefore, I suppose YANG models can be used for the interface between NFV > MANO and ALTO server. In such scenario, the ALTO server is acting as an app > for the NFV MANO to constantly pull info from it. > > > > Two quick questions. One, could you please post s link to the aforementioned RESTful API? Second, constant pulling can be frowned upon by some. Is there a push mechanism? > I am wondering the other direction of interaction. What information ALTO > may provide to NFV-MANO. The main goal of ALTO is to provide as simple as > possible network information for clients to utilize. What information will > NFV need that ALTO may provide? > > > > [fq] One thing I can think of is in the sfc usecase. In the SFC, the SFF > should choose a suitable SF to forward the packet flow. Such choice should > based on the bandwidth, the distance, and etc. of the SFs. Therefore, in > this case the SFF may need to ask ALTO server for the network info of > different SFs. In this scenario, the SFF acts as ALTO client, and SFs are > the hosts. > > > > This makes sense. > > > Your draft appears to suggest one more dimension of interaction: "ALTO > server...even should be able to inform the NFV MANO to scale up certain > > service at a proper point." This is interesting but will imply more > substantial extensions, right? > > [fq] Yes. Such interaction will require more extension for ALTO. I don’t > know if this is possible in ALTO now? What’s your comments? > > The key issue is that this will require (1) submitting service requests to ALTO servers--so far ALTO is limited to be read only (idempotent read of network info; (2) an interface exposed by NFV-MANO to receive such scaling requests. Is there such an interface in MANO? There is no interface for (1), for now. A value of ALTO is to provide locations for such scaling, as you wrote. Thanks! Richard > > > > > Richard > > > > > > > > > > > > > > > > On Wed, Mar 11, 2015 at 6:20 AM, Qiao Fu <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > > Hi, Lingli. Thank you for the comments. > A usecase I can think of within the DC is the sfc (service function > chaining). In the sfc, there is a sff (service function forwarder) > responsible for forwarding certain flow to the specific sf (service > function). When the flow finished in the sf, it will get back to the sff > and will be directed to the next sf on the sfp (service function path). > Therefore, the sff may need information to know which sf is located at > which rack so that it can optimize the sfp and reduce latency between the > sf and itself. I think a wise choice is for the sff to ask auto server for > this info. > In such usecase, rack ID or even server ID is important information for > the sff. I don't know if this scenario makes sense to you? > Thank you and looking forward to your feedback:) > > > > -----邮件原件----- > 发件人: 邓灵莉/Lingli Deng [mailto:[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] > 发送时间: 2015年3月9日 11:14 > 收件人: 'Qiao Fu'; [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > 抄送: [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>; 'Songhaibin (A)' > 主题: RE: New Version Notification for draft-fu-alto-nfv-usecase-04.txt > > Hi Qiao, > > Thanks for the interesting discussion around endpoint property for VNFs. > > In terms of VNF migration and its impact on endpoint geo-location property > design, I see there are two potential cases: inter-DC migration and > intra-DC migration. > As you can see from the current design for endpoint geo-location property, > the intra-DC migration might not be reflected by the current design unless > we introduce something like server-id or rack-id? > But such information is too low-level I suspect and maybe considered > sensitive or lose its practical meaning once the ALTO client is located > outside the DC domain in question. > While within the DC, who would be the ALTO client for such information? > > Regards, > Lingli > > > -----Original Message----- > > From: Qiao Fu [mailto:[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] > > Sent: Monday, March 09, 2015 10:35 AM > > To: [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> > > Cc: [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>; 'Songhaibin > (A)'; '邓灵莉/Lingli Deng' > > Subject: 转发: New Version Notification for > draft-fu-alto-nfv-usecase-04.txt > > > > Hi, all. I have just updated the following draft. This draft proposes a > usecase of > > ALTO in the NFV scenario. And possible property extension is added and > > discussed in this update. Such extension may be included in another > draft: > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__datatracker.ietf.org_doc_draft-2Ddeng-2Dalto-2Dp2p-2Dext_&d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=j4HhAKnIlF-2BeYwgSzklCj2CfbNTN5VF7DM0qf3c_w&e= > > Your comments and suggestions are more than welcome. Thank you! > > > > > > -----邮件原件----- > > 发件人: [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');> [mailto: > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] > > 发送时间: 2015年3月9日 10:27 > > 收件人: Haibin Song; Qiao Fu; Qiao Fu; Haibin Song; Zhen Cao; Zehn Cao > > 主题: New Version Notification for draft-fu-alto-nfv-usecase-04.txt > > > > > > A new version of I-D, draft-fu-alto-nfv-usecase-04.txt > > has been successfully submitted by Qiao Fu and posted to the > > IETF repository. > > > > Name: draft-fu-alto-nfv-usecase > > Revision: 04 > > Title: What's the Impact of Virtualization on > Application-Layer Traffic > > Optimization (ALTO)? > > Document date: 2015-03-08 > > Group: Individual Submission > > Pages: 9 > > URL: > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_internet-2Ddrafts_draft-2Dfu-2Dalto-2Dnfv-2Dusecase-2D04.txt&d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=0WsmAkejAMhADn5ePfoCD17b6AwEL83_TtOR7iXu7vs&e= > > Status: > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfu-2Dalto-2Dnfv-2Dusecase_&d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=AqfqItcQkOjMc0Y5HhNUIrV5C6kuYC0-uibuL3L2Ito&e= > > Htmlized: > https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_html_draft-2Dfu-2Dalto-2Dnfv-2Dusecase-2D04&d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=ZGJSB3cW4LiC2a3y0xuK3d6__AdHXeW5bg4g_bNdCWY&e= > > Diff: > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dfu-2Dalto-2Dnfv-2Dusecase-2D04&d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=JbRTHmXk9BQ0Gr9ShXt8GyDpz2-ZfLza_R441tyJS7I&e= > > > > Abstract: > > This documentation presents a use case of Application-Layer Traffic > > Optimization (ALTO) with the emergence of Network Function > > Virtualization (NFV). The Application-Layer Traffic Optimization > > (ALTO) Service provides network information (e.g., basic network > > location structure and preferences of network paths) with the goal of > > modifying network resource consumption patterns while maintaining or > > improving application performance. The emerging NFV, which is > > currently being in progress in ETSI NFV, leverages standard IT > > virtualisation technology to consolidate many network equipment types > > onto industry standard high-volume servers, switches, and storage. > > The use case presented in this document discusses the impact of > > virtualization on the ALTO protocol. An architecture is proposed for > > the interface between NFV MANO and ALTO server. And possible end > > point property extention is also discussed for such usecase. > > > > > > > > > > Please note that it may take a couple of minutes from the time of > submission > > until the htmlized version and diff are available at tools.ietf.org > <https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=AwMFaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=11XRRYblnWYivla6bmnUEkceMpSe_U2Ru0lhABWMPkI&s=XUXn9B81pYKMbVRp_V9IdoUuSuKIm8tt15xW_IktTc4&e=> > . > > > > The IETF Secretariat > > > > > > > > _______________________________________________ > alto mailing list > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=w5LHrNAaivqMsvKzQhXUhqvBnMyKVSRsunfbBC6O5pA&e= > -- Richard
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
