IETF Logo Mail Archive

Re: [GROW] discuss about draft-luo-grow-ts-use-cases-00

joel jaeggli <joelja@bogus.com> Mon, 30 May 2016 04:30 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCBF12B01E for <grow@ietfa.amsl.com>; Sun, 29 May 2016 21:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.734
X-Spam-Level:
X-Spam-Status: No, score=-6.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJIcJcUm24LX for <grow@ietfa.amsl.com>; Sun, 29 May 2016 21:30:54 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B0E12B012 for <grow@ietf.org>; Sun, 29 May 2016 21:30:54 -0700 (PDT)
Received: from mb-2.local ([IPv6:2601:b00:c503:f01f:505c:a494:bfde:9c1a]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u4U4UcdJ006438 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 30 May 2016 04:30:40 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:b00:c503:f01f:505c:a494:bfde:9c1a] claimed to be mb-2.local
To: "luoyuj.gd" <luoyuj.gd@chinatelecom.cn>, grow <grow@ietf.org>
References: <mailman.0.1463541741.1293.grow@ietf.org> <57426DC7.5080003@chinatelecom.cn>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <379dc67f-737c-d62e-f9d1-8706601f4a70@bogus.com>
Date: Mon, 30 May 2016 00:42:56 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <57426DC7.5080003@chinatelecom.cn>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="8eVCsd5x6XctxE0tCihAUQD3xNjU0OBlG"
Archived-At: <http://mailarchive.ietf.org/arch/msg/grow/1GWwXWLvXcUB4UTLHbf5sq4kQh4>
Subject: Re: [GROW] discuss about draft-luo-grow-ts-use-cases-00
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 May 2016 04:30:59 -0000

On 5/23/16 4:41 AM, luoyuj.gd wrote:
> Hi everyone，
> 
>  
> 
>     I'm Jenny Luo，one of the writers of draft-luo-grow-ts-use-cases-00.
> The draft is mainly about*usecases for traffic steering in operator
> network*, and we introduce it on 95th IETF meeting in *Buenos Aires.*
> 
>     Our team received some comments and we appreciated very much for
> that.   The comments are listed as follows and we would like to discuss
> them with the relevant experts .  We would really appreciate it if you
> could offer more description about the comments, so we could understand
> them correctly.
> 
>  
> 
> * Comments:*
> ­1. The requirements are components that sometimes are impossible to
> implement.Concerns that transferring requirements to implementations are
> difficult. Fine granularity is a difficult implementation.
> ­ 2. With the right set of computation someone can do what is needed in
> a network.Heavily lifting needed to get it through
> ­ 3. Control system: Add a delay and a random generator
> ­ 4. What is the different to do it random. Other parties are working on
> other different constraintorgs.
> ­ 5. Delaying computation, Implementing at the edge and monitoring inside.
> ­ 6. Not everybody have sufficient resources. Can´t be emulated without
> resources.  How much spare capacity or overloading in your network? If
> you can afford serious spare capacity you can aprox. to a good
> contribution by delaying.

Not sure how these networks are architected, but in my experience
network cores are rarely over-subscribed unless degraded. interconnects
between network's may be but political/economic reasons for them being
so do not see like a great basis for coordination on traffic
engineering. so that leaves customer facing edges.


> ­ 7. How can we schedule flows automatically with fine granularity?
>  
> 
>   2016-05-20
> 
> ------------------------------------------------------------------------
> 
> *Jenny Luo*
> 
> Data Communication Research Department
> 
> Guangzhoou Research Institute of ChinaTelecom
> 
> Tel：+86 20 38639134
> 
> Mobile：18924152329
> 
> E-mail：luoyuj.gd@chinatelecom.cn <mailto:luoyuj.gd@chinatelecom.cn>
> 
>  
> 
> 
> _______________________________________________
> GROW mailing list
> GROW@ietf.org
> https://www.ietf.org/mailman/listinfo/grow
>

v2.23.0 | Report a Bug | By Email