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

[Christopher Morrow <[e-mail]>]

and I should have said: "I'm just a guy in the WG meeting... no one special"

On Tue, May 31, 2016 at 9:42 PM, Christopher Morrow <
[e-mail]> wrote:

>
>
> On Sun, May 29, 2016 at 6:42 PM, joel jaeggli <[e-mail]> wrote:
>
>> 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.
>>
>>
> ​Even outside of congested cores folk MAY want to do things like: "Hey,
> for X pesos less a bit you can send your bits the long-way-around!" and let
> users mark their packets for delivery on the long path.
>
> That seems fine, to me... it seems a bit nutty as a configuration
> nightmare, but sure you COULD do that sort of gymnastics.​
>
> ​I believe I said about this at the mic in EZE, I'd still say the same
> thing today.
> The document basically wants to outline a set of potentially programmable
> methods to say to customers:  "Mark with X, get Y treatment"  and then
> deploy configuration that would honor that set of policies to the network.
>
> I don't think this is, particularly, a 'Global Routing Operations'
> problem, it's generally an operations&mangement problem to solve.
>
>
>>
>> > ­ 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：[phone]
>> >
>> > Mobile：[phone]
>> >
>> > E-mail：[e-mail] <mailto:[e-mail]>
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > GROW mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/grow
>> >
>>
>>
>>
>> _______________________________________________
>> GROW mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/grow
>>
>>
>