internet-drafts | 29 May 16:36 2015
Picon

I-D Action: draft-ietf-alto-incr-update-sse-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Application-Layer Traffic Optimization Working Group of the IETF.

        Title           : ALTO Incremental Updates Using Server-Sent Events (SSE)
        Authors         : Wendy Roome
                          Y. Richard Yang
	Filename        : draft-ietf-alto-incr-update-sse-00.txt
	Pages           : 27
	Date            : 2015-05-29

Abstract:
   The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol
   provides network related information to client applications so that
   clients may make informed decisions.  To that end, an ALTO Server
   provides Network and Cost Maps.  Using those maps, an ALTO Client can
   determine the costs between endpoints.

   However, the ALTO protocol does not define a mechanism to allow an
   ALTO client to obtain updates to those maps, other than by
   periodically re-fetching them.  Because the maps may be large
   (potentially tens of megabytes), and because only parts of the maps
   may change frequently (especially Cost Maps), that can be extremely
   inefficient.

   Therefore this document presents a mechanism to allow an ALTO Server
   to provide updates to ALTO Clients.  Updates can be both immediate,
   in that the server can send updates as soon as they are available,
   and incremental, in that if only a small section of a map changes,
   the server can send just the changes.
(Continue reading)

Wendy Roome | 29 May 16:24 2015

Re: Interop test

Folks,

Rather than simply update the last test, I suggest a new approach,
outlined below.

**** General ****

The interop test defines two network maps: the default network map and an
alternate network map. We specify the PIDs and CIDRs for each map. For
each network map, the interop test defines the numerical-mode values for
the routingcost and hopcount cost-metrics. The interop test does not
define ordinal values for those metrics. Instead, each ALTO server may
assign ordinal values however it wants, as long as the ordinal values
preserve the numerical values.

The interop test also defines a custom endpoint property, say
"priv:ietf-type", and specifies the values.

**** Approach & Philosophy ****

Rather than specifying every detail, as in the previous interop test, this
iteration only specifies what is absolutely necessary. That is, the PIDs
in the network maps, the costs between PIDs, and the enpdoint property
values. Everything else -- resource ids, uris, cost-type names, etc. -- is
up to the server. Thus each server is completely characterized by two
parameters:

* The URI of its IRD.
* The resource id of its alternate map (if provided).

(Continue reading)

Wendy Roome | 27 May 22:04 2015

Re: Review of draft-ietf-alto-deployments-11

Folks,

Vijay Gurbani asked me to do a detailed review of the alto-deployments
draft before we complete Last Call.

My review is long, so I attached it as a text file. Hopefully the list
server will save that file somewhere and provide a link when it forwards
this. If not, I will put the file on my server.

Overall, I found several minor issues, plus numerous nits. Fortunately
they should be easy to fix.

I only found two major issues. First, Section 2.2.2 is very confusing, and
I suggest rewriting a few paragraphs (details in the review file).

Second, it references a number of expired drafts, some going back to 2010.
They should be updated to reference the latest versions. And if an expired
draft does not have a newer version, consider deleting the reference.

	- Wendy Roome

Review of ALTO Deployment Considerations, draft-ietf-alto-deployments-11, March 2, 2015

Reviewer: Wendy Roome,  May 27, 2015.

Major issues:

---------
(Continue reading)

internet-drafts | 22 May 20:49 2015
Picon

I-D Action: draft-ietf-alto-multi-cost-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Application-Layer Traffic Optimization Working Group of the IETF.

        Title           : Multi-Cost ALTO
        Authors         : Sabine Randriamasy
                          Wendy Roome
                          Nico Schwan
	Filename        : draft-ietf-alto-multi-cost-00.txt
	Pages           : 23
	Date            : 2015-05-22

Abstract:
   The ALTO (Application Layer-Traffic Optimization) Protocol
   ([RFC7285]) defines several services that return various metrics
   describing the costs between network endpoints.  For example, when
   downloading a file that is mirrored on several sites, a user
   application may use these ALTO cost metrics to determine the most
   efficient mirror site.

   An ALTO Server may offer a variety of cost metrics, based on latency,
   bandwidth, hop count, jitter, or whatever else the ALTO Server deems
   useful.  When selecting a mirror site, a client may consider more
   than one metric, perhaps trading bandwidth for latency.  While the
   base ALTO Protocol allows a client to use more than one cost metric,
   to do so, the client must request each metric separately.  This
   document defines a new service that allows a client to retrieve
   several cost metrics with one request, which is considerably more
   efficient.  In addition, this document extends the ALTO constraint
   tests to allow a user to specify an arbitrary logical combination of
(Continue reading)

Bertz, Lyle T [CTO] | 20 May 19:58 2015
Picon

RFC 7285 JSON Schema

Enclosed is a JSON Schema document for ALTO that uses version 4 JSON Schema notation.   It has been used with
client side editors such as JSON Editor (demo at http://jeremydorn.com/json-editor/) to visualize the
forms and help debug both schema and RFC examples.

Use it as you like, it is presented here AS IS (no warranties expressed or implied ;)) as to its accuracy but it
has been successfully tested against RFC examples and other working ALTO code.

MINOR issues exist / were discovered as part of this work:
1. MINOR ERROR IN RFC 7285 there an issue in Section 9.2.3 Example, the last endpoint-property (path is
#/resources/endpoint-property/capabilities) has a comma even though it is the last property in the object.

2. ANNOYANCES IN JSON Editor reloading the schema can be problematic based upon the browser you use and the
editor does NOT parse dotted property names well at all (only displays the last portion of the name after
the last '.').

3. MINOR ISSUES IN the Schema -
a. There is heavy use of pattern properties & 'additional properties = true' which is problematic for some
tools but in JSON Schema's definition.
b. Overriding the meta definition in the responses is a bit challenging for editors as the property appears
twice in the base object reference - depending upon the implementation of the inclusion method in JSON
schema when using a $ref results and a property override, the editor may be a bit inconsistent in the UI and
how default values are implemented when the form is initially loaded.

4. Even though it is included in the schema, 'code' (error code) is never used - we may look at formally
defining a response type in the schema to correct that.

I hope others find it useful.  If anyone makes extensions / corrections it would be great if they make it (or
it's location) available on the list.

Lyle
(Continue reading)

Vijay K. Gurbani | 20 May 15:18 2015

WG reviewer needed for draft-ietf-alto-deployments-11

Folks:  The WGLC for draft-ietf-alto-deployments-11 ended on May 17,
2015 [1].

It would have been good to get a WG review of the document before we
move it ahead.  The last review portions of the draft had were in Dec
2013 [2].

The chairs would kindly request one (or more) WG members to post a
review of the draft.  Can interested volunteers please get back to
me and Jan as soon as they can with a short email on their interest and
intent to review the draft.

We will extend the WGLC for a short break (preferably no more than a
week) until a reviewer has been identified and the review is done.

Please get back to Jan and me on your intent and interest to review
the draft.

[1] http://www.ietf.org/mail-archive/web/alto/current/msg02800.html
[2] http://www.ietf.org/mail-archive/web/alto/current/msg02335.html

Thanks,

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

(Continue reading)

Vijay K. Gurbani | 20 May 15:10 2015

Adoption of incremental updates using server-side notifications

Dear authors: As ratified on the email list [1], please
prepare to submit a WG -00 version of incr-update-sse as soon as you
can.

Thanks,

[1] http://www.ietf.org/mail-archive/web/alto/current/msg02801.html

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

Vijay K. Gurbani | 20 May 15:07 2015

Adoption of multi-cost

Dear authors of multi-cost: As ratified on the email list [1], please
prepare to submit a WG -00 version of multi-cost as soon as you can.

Thanks,

[1] http://www.ietf.org/mail-archive/web/alto/current/msg02803.html

- vijay
--

-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

Lingli Deng | 8 May 13:22 2015

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>
  • To: '邓灵莉/Lingli Deng' <denglingli at chinamobile.com>, <alto at ietf.org>
  • Cc: zhencao.ietf at gmail.com
  • Date: Wed, 11 Mar 2015 18:20:26 +0800
  • In-reply-to: <008d01d05a17$08f5d2a0$1ae177e0$ <at> com>
  • References: <SNT146-DS20A7790DF96D11D711CB7CE81B0 <at> phx.gbl> <008d01d05a17$08f5d2a0$1ae177e0$ <at> 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 >
    <div><div dir="ltr">&nbsp;Hi Qiao,<br>&nbsp;<br>I am planning working on the endpoint extensions that you proposed for NFV usecases in March.<br>Would be happy to have a further discussion before getting started.<br>&nbsp;<br>As discussed earlier,&nbsp; I&nbsp;propose&nbsp;extensions to the current geolocation EP property as follows (also useful for other datacenter scenario I suppose): <br>&nbsp;<br>Extending the geolocation_precision_set = ["countrycode", "boundingbox", "circle", "DC"]<br>If the "precision" attribute of the "geolocation" property of an&nbsp;endpoint is "DC", the following "content" attribute is&nbsp;defined as a four-element JSON object "DC":<br><br>&nbsp;&nbsp;&nbsp;DC = {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "rack-id" : number, <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "server-id" : number<br>&nbsp;&nbsp;&nbsp; }<br>&nbsp;<br>Would&nbsp;the&nbsp;this&nbsp;address your usecase for VNF migration?<br>&nbsp;<br>Lingli<br>&nbsp;<br>-----&#37038;&#20214;&#21407;&#20214;-----<br>From: Qiao Fu &lt;<a href="mailto:fuqiao1 <at> DOMAIN.HIDDEN">fuqiao1 at outlook.com</a>&gt;<br><li>To: '&#37011;&#28789;&#33673;/Lingli Deng' &lt;<a href="mailto:denglingli <at> DOMAIN.HIDDEN">denglingli at chinamobile.com</a>&gt;,  &lt;<a href="mailto:alto <at> DOMAIN.HIDDEN">alto at ietf.org</a>&gt;</li>
    <li>Cc: <a href="mailto:zhencao.ietf <at> DOMAIN.HIDDEN">zhencao.ietf at gmail.com</a>
    </li>
    <li>Date: Wed, 11 Mar 2015 18:20:26 +0800</li>
    <li>In-reply-to: &lt;008d01d05a17$08f5d2a0$1ae177e0$ <at> com&gt;</li>
    <li>References: &lt;<a href="http://www.ietf.org/mail-archive/web/alto/current/msg02745.html">SNT146-DS20A7790DF96D11D711CB7CE81B0 <at> phx.gbl</a>&gt; &lt;008d01d05a17$08f5d2a0$1ae177e0$ <at> com&gt;</li>  <br><br>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:)
    
    -----&#37038;&#20214;&#21407;&#20214;-----
    &#21457;&#20214;&#20154;: &#37011;&#28789;&#33673;/Lingli Deng [<a href="mailto:denglingli" rel="nofollow">mailto:denglingli</a> at chinamobile.com] 
    &#21457;&#36865;&#26102;&#38388;: 2015&#24180;3&#26376;9&#26085; 11:14
    &#25910;&#20214;&#20154;: 'Qiao Fu'; alto at ietf.org
    &#25220;&#36865;: zhencao.ietf at gmail.com; 'Songhaibin (A)'
    &#20027;&#39064;: 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
    
    &gt; -----Original Message-----
    &gt; From: Qiao Fu [<a href="mailto:fuqiao1" rel="nofollow">mailto:fuqiao1</a> at outlook.com]
    &gt; Sent: Monday, March 09, 2015 10:35 AM
    &gt; To: alto at ietf.org
    &gt; Cc: zhencao.ietf at gmail.com; 'Songhaibin (A)'; '&#37011;&#28789;&#33673;/Lingli Deng'
    &gt; Subject: &#36716;&#21457;: New Version Notification for draft-fu-alto-nfv-usecase-04.txt
    &gt; 
    &gt; Hi, all. I have just updated the following draft. This draft proposes a usecase of
    &gt; ALTO in the NFV scenario. And possible property extension is added and
    &gt; discussed in this update. Such extension may be included in another draft:
    &gt; <a href="http://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/" rel="nofollow">http://datatracker.ietf.org/doc/draft-deng-alto-p2p-ext/</a>
    &gt; Your comments and suggestions are more than welcome. Thank you!
    &gt; 
    &gt; 
    &gt; -----&#37038;&#20214;&#21407;&#20214;-----
    &gt; &#21457;&#20214;&#20154;: internet-drafts at ietf.org [<a href="mailto:internet-drafts" rel="nofollow">mailto:internet-drafts</a> at ietf.org]
    &gt; &#21457;&#36865;&#26102;&#38388;: 2015&#24180;3&#26376;9&#26085; 10:27
    &gt; &#25910;&#20214;&#20154;: Haibin Song; Qiao Fu; Qiao Fu; Haibin Song; Zhen Cao; Zehn Cao
    &gt; &#20027;&#39064;: New Version Notification for draft-fu-alto-nfv-usecase-04.txt
    &gt; 
    &gt; 
    &gt; A new version of I-D, draft-fu-alto-nfv-usecase-04.txt
    &gt; has been successfully submitted by Qiao Fu and posted to the
    &gt; IETF repository.
    &gt; 
    &gt; Name:		draft-fu-alto-nfv-usecase
    &gt; Revision:	04
    &gt; Title:		What's the Impact of Virtualization on Application-Layer Traffic
    &gt; Optimization (ALTO)?
    &gt; Document date:	2015-03-08
    &gt; Group:		Individual Submission
    &gt; Pages:		9
    &gt; URL:
    &gt; <a href="http://www.ietf.org/internet-drafts/draft-fu-alto-nfv-usecase-04.txt" rel="nofollow">http://www.ietf.org/internet-drafts/draft-fu-alto-nfv-usecase-04.txt</a>
    &gt; Status:         <a href="https://datatracker.ietf.org/doc/draft-fu-alto-nfv-usecase/" rel="nofollow">https://datatracker.ietf.org/doc/draft-fu-alto-nfv-usecase/</a>
    &gt; Htmlized:       <a href="http://tools.ietf.org/html/draft-fu-alto-nfv-usecase-04" rel="nofollow">http://tools.ietf.org/html/draft-fu-alto-nfv-usecase-04</a>
    &gt; Diff:           <a href="http://www.ietf.org/rfcdiff?url2=draft-fu-alto-nfv-usecase-04" rel="nofollow">http://www.ietf.org/rfcdiff?url2=draft-fu-alto-nfv-usecase-04</a>
    &gt; 
    &gt; Abstract:
    &gt;    This documentation presents a use case of Application-Layer Traffic
    &gt;    Optimization (ALTO) with the emergence of Network Function
    &gt;    Virtualization (NFV).  The Application-Layer Traffic Optimization
    &gt;    (ALTO) Service provides network information (e.g., basic network
    &gt;    location structure and preferences of network paths) with the goal of
    &gt;    modifying network resource consumption patterns while maintaining or
    &gt;    improving application performance.  The emerging NFV, which is
    &gt;    currently being in progress in ETSI NFV, leverages standard IT
    &gt;    virtualisation technology to consolidate many network equipment types
    &gt;    onto industry standard high-volume servers, switches, and storage.
    &gt;    The use case presented in this document discusses the impact of
    &gt;    virtualization on the ALTO protocol.  An architecture is proposed for
    &gt;    the interface between NFV MANO and ALTO server.  And possible end
    &gt;    point property extention is also discussed for such usecase.
    &gt; 
    &gt; 
    &gt; 
    &gt; 
    &gt; Please note that it may take a couple of minutes from the time of submission
    &gt; until the htmlized version and diff are available at tools.ietf.org.
    &gt; 
    &gt; The IETF Secretariat
    &gt;  		 	   		  </div></div>
    
    Vijay K. Gurbani | 29 Apr 16:31 2015

    Consideration for ALTO topology extensions drafts

    Folks: At the Dallas IETF meeting, Richard Yang presented the ALTO 
    topology extensions [1,2].
    
    These are important drafts for the WG to consider; the balance of
    comments at the mic in Dallas reflected support for these drafts.
    The drafts fulfill an important WG charter item.
    
    While we did not take a hum to adopt these drafts in the Dallas IETF,
    we did take a hum that indicated the importance of these drafts to
    the WG.  The drafts provide a good path towards technical answers on
    providing abstract graph representations of network topology and a new
    improved path-vector cost mode for high bandwidth applications.
    
    Absent any other solutions in front of the WG, the expectation is that
    these drafts will be adopted sometimes in the near future.  This email
    serves as a reminder to the WG to kindly review these drafts and
    provide comments to the authors on the contents between now and the
    next face-to-face meeting in the summer.
    
    [1] http://datatracker.ietf.org/doc/draft-yang-alto-path-vector/
    [2] http://datatracker.ietf.org/doc/draft-yang-alto-topology/
    
    Thank you,
    
    - vijay
    --
    
    -- 
    Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
    1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
    Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
    Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
    
    
    Vijay K. Gurbani | 29 Apr 16:10 2015

    Adopting draft-randriamasy-alto-multi-cost-10

    Folks: At the Dallas IETF meeting, there was a hum in favour of
    adopting ALTO multi-cost draft [1] as a WG item.
    
    This email serves to ratify the consensus gauged through the hum.
    
    There will be a period of one week to indicate any objections, including
    a solid defense of the objection, to moving the draft to WG status.
    
    After the week from the arrival of this email to the WG list, and
    assuming no objections, the draft authors are requested to kindly
    submit the document as a WG -00 version.
    
    [1] https://datatracker.ietf.org/doc/draft-randriamasy-alto-multi-cost/
    
    Thank you,
    
    - vijay
    --
    
    -- 
    Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
    1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
    Email: vkg <at> {bell-labs.com,acm.org} / vijay.gurbani <at> alcatel-lucent.com
    Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq
    
    

    Gmane