[alto] 答复: 答复: New Version Notification for draft-fu-alto-nfv-usecase-04.txt

["Fu Qiao" <[e-mail]>]

Hi, Lingli. Thank you for the work. I think the extension you address makes
sense to me. There is another usecase where there could be multiple VMs in
one VNF. Therefore in this scenario we can hardly define the geo-location of
the VNF. In such case, I think maybe we can use the geo-location of the
ingress VM as the geo-location of the whole VNF. I don’t know if this makes
sense to you?

 

发件人: Lingli Deng [mailto:[e-mail]] 
发送时间: 2015年5月8日 19:23
收件人: [e-mail]
抄送: [e-mail]
主题: RE: 答复: New Version Notification for
draft-fu-alto-nfv-usecase-04.txt

 

 Hi Qiao,
 
I am planning working on the endpoint extensions that you proposed for NFV
usecases in March.
Would be happy to have a further discussion before getting started.
 
As discussed earlier,  I propose extensions to the current geolocation EP
property as follows (also useful for other datacenter scenario I suppose): 
 
Extending the geolocation_precision_set = ["countrycode", "boundingbox",
"circle", "DC"]
If the "precision" attribute of the "geolocation" property of an endpoint is
"DC", the following "content" attribute is defined as a four-element JSON
object "DC":

   DC = {
                "rack-id" : number, 
                "server-id" : number
    }
 
Would the this address your usecase for VNF migration?
 
Lingli
 
-----邮件原件-----
From: Qiao Fu <fuqiao1 at outlook.com <mailto:[e-mail]> >

・  To: '邓灵莉/Lingli Deng' <denglingli at chinamobile.com
<mailto:[e-mail]> >, <alto at ietf.org
<mailto:[e-mail]> >

・  Cc: zhencao.ietf at gmail.com <mailto:[e-mail]> 

・  Date: Wed, 11 Mar 2015 18:20:26 +0800

・  In-reply-to: <008d01d05a17$08f5d2a0$1ae177e0$@com>

・  References: <[e-mail]
<http://www.ietf.org/mail-archive/web/alto/current/msg02745.html> >
<008d01d05a17$08f5d2a0$1ae177e0$@com> 

  _____  

 

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:denglingli at chinamobile.com] 
发送时间: 2015年3月9日 11:14
收件人: 'Qiao Fu'; alto at ietf.org
抄送: zhencao.ietf at gmail.com; '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:fuqiao1 at outlook.com]
> Sent: Monday, March 09, 2015 10:35 AM
> To: alto at ietf.org
> Cc: zhencao.ietf at gmail.com; '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:
> http://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/
> Your comments and suggestions are more than welcome. Thank you!
> 
> 
> -----邮件原件-----
> 发件人: internet-drafts at ietf.org [mailto:internet-drafts at ietf.org]
> 发送时间: 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:
> http://www.ietf.org/internet-drafts/draft-fu-alto-nfv-usecase-04.txt
> Status:
https://datatracker.ietf.org/doc/draft-fu-alto-nfv-usecase/
> Htmlized:       http://tools.ietf.org/html/draft-fu-alto-nfv-usecase-04
> Diff:
http://www.ietf.org/rfcdiff?url2=draft-fu-alto-nfv-usecase-04
> 
> 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.
> 
> The IETF Secretariat
>