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

From: 邓灵莉/Lingli Deng <[email-masked]>
Date: Mon, 9 Mar 2015 11:13:36 +0800

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-masked]]
> Sent: Monday, March 09, 2015 10:35 AM
> To: [email-masked]
> Cc: [email-masked]; '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!
> 
> 
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 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
>

---

From: Qiao Fu <[email-masked]>
Date: Wed, 11 Mar 2015 18:20:26 +0800

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-masked]] 
发送时间: 2015年3月9日 11:14
收件人: 'Qiao Fu'; [email-masked]
抄送: [email-masked]; 'Songhaibin (A)'
主题: RE: New Version Notification for draft-fu-alto-nfv-usecase-04.txt

Hi Qiao,

Regards,
Lingli

---

From: Qiao Fu <[email-masked]>
Date: Mon, 9 Mar 2015 10:35:13 +0800

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!

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 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

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:

The IETF Secretariat

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 20 Mar 2015 22:26:32 -0400

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?

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?

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?

Richard

On Wed, Mar 11, 2015 at 6:20 AM, Qiao Fu <[email-masked]> wrote:

> 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?
> 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.
> 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=
> 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:
> _______________________________________________
> alto mailing list
> [email-masked]
>
> 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=

---

From: Fu Qiao <[email-masked]>
Date: Sat, 21 Mar 2015 11:52:09 -0500

Hi, Richard. Thank you for your comments. I put some inlines as follows. Looking forward to have more discussion with you. 

发件人: [email-masked] [mailto:[email-masked]] 代表 Y. Richard Yang
发送时间: 2015年3月20日 21:27
收件人: Qiao Fu
抄送: 邓灵莉/Lingli Deng; IETF ALTO; [email-masked]
主题: 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.

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. 

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?

Richard

 

-----邮件原件-----
发件人: 邓灵莉/Lingli Deng [mailto:[email-masked]]
发送时间: 2015年3月9日 11:14
收件人: 'Qiao Fu'; [email-masked]
抄送: [email-masked]; 'Songhaibin (A)'
主题: RE: New Version Notification for draft-fu-alto-nfv-usecase-04.txt

Hi Qiao,

Regards,
Lingli

> https://urldefense.proofpoint.com/v2/url?u=http-3A__datatracker.ietf.org_doc_draft-2Ddeng-2Dalto-2Dp2p-2Dext_ <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=> &d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=j4HhAKnIlF-2BeYwgSzklCj2CfbNTN5VF7DM0qf3c_w&e=
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ietf.org_internet-2Ddrafts_draft-2Dfu-2Dalto-2Dnfv-2Dusecase-2D04.txt <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=> &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_ <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=> &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 <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=> &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 <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=> &d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=JbRTHmXk9BQ0Gr9ShXt8GyDpz2-ZfLza_R441tyJS7I&e=
>
> Abstract:

_______________________________________________
alto mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto <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=> &d=AwIGaQ&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=832Zza2OXdKCFUMRkp4xUeZfH16qHuUha0mQm3g7mw0&s=w5LHrNAaivqMsvKzQhXUhqvBnMyKVSRsunfbBC6O5pA&e=

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 23 Mar 2015 15:04:40 -0400

Hi Qiao,

Please see below.

On Saturday, March 21, 2015, Fu Qiao <[email-masked]> wrote:

> Hi, Richard. Thank you for your comments. I put some inlines as follows.
> Looking forward to have more discussion with you.
>
>
>
> *发件人:* [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');> [mailto:
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *代表 *Y. Richard
> Yang
> *发送时间:* 2015年3月20日 21:27
> *收件人:* Qiao Fu
> *抄送:* 邓灵莉/Lingli Deng; IETF ALTO; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *主题:* Re: [alto] 答复: New Version Notification for
> draft-fu-alto-nfv-usecase-04.txt
>
>
>
> Dear Qiao, Lingli,
>
> [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?

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

> [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-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> 发件人: 邓灵莉/Lingli Deng [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> 发送时间: 2015年3月9日 11:14
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> 抄送: [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>; 'Songhaibin (A)'
> > From: Qiao Fu [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> > To: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> > Cc: [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>; 'Songhaibin
> (A)'; '邓灵莉/Lingli Deng'
> > 发件人: [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');> [mailto:
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> > 发送时间: 2015年3月9日 10:27
> > 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
> >
>
>
>
>
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>

-- 
Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 23 Mar 2015 15:20:37 -0400

Some additional quick comment.

On Monday, March 23, 2015, Y. Richard Yang <[email-masked]> wrote:

> Hi Qiao,
>
> Please see below.
>
> On Saturday, March 21, 2015, Fu Qiao <[email-masked]
>> *发件人:* [email-masked] [mailto:[email-masked]] *代表 *Y.
>> Richard Yang
>> *发送时间:* 2015年3月20日 21:27
>> *收件人:* Qiao Fu
>> 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?
>>
>>
>>
> some. Is there a push mechanism?

I see that not only NFV will have an impact on ALTO server info. Recently,
an issue I know some are thinking is how to compute and adjust ALTO info in
a setting with complex network policies. For example, GBP may define
policies that can have a substantial impact on ALTO network and cost maps.
As an example, EPG a in one PID i and EPG b in PID j. If the "contract"
changes from Allow to Deny (or Redirect in the setting of service chaining)
for the two EPGs, costs may change substantially, and adaptive apps on top
may want to know... Hence, this will be a generic issue, I feel.

Richard

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

-- 
Richard