draft-ietf-tewg-principles-00.txt (Former TEWG Framework Draft)

["Awduche, Daniel" <awduche@movaz.com>]

The title of the TEWG Framework draft has been changed from:
'A Framework for Internet Traffic Engineering' 
(draft-ietf-tewg-framework-05.txt) to: 'Overview and 
Principles of Internet Traffic Engineering.' The new 
draft is available as: draft-ietf-tewg-principles-00.txt. 
The name change was suggested by the IESG. A few minor 
editorial changes were also recommended by the IESG.

The following transcript summarizes the  comments from 
the IESG and the editorial changes made to address 
them. The changes are editorial in nature and do 
not affect the substance of the document. If you have any 
comments please let us know within the next 7 days, as 
the IESG would like to put the document back on their 
agenda in early September. Thanks to Xipeng for taking 
care of the changes: 

- From Bert Wijnen
> All in all I think this is OK as informational, except I am
> (and with me others) not happy with the title (see 1st comment
> below). Besides that I have some more comments that you may want
> to look through, give me some answers and/or update the text
> a bit more.
> 
> - It seems (and I have heard that from various others who read it)
>   that it is more of a "te 101" or an "overview of te issues"
>   than a "framework". 
>   From a framework document, I would rather see a description how
>   all things fit together and where particular (possible future)
>   pieces of work need to fit in. I see very little of that.
>   So in that sense... if we accpet this (which the WG seems to
>   have agreed to), then I would call it "overview of te issues"
>   or some such thing.
> 
> - Section 4.5.7 (still) talks about an ECM WG.
>   Might want to update doc to refer to RFC3124

Done.

> 
> - Comments from RTFM (Nevil Brownlee) since it is mentioned in
>   section 4.5.6
> 
>  * Overall the draft is a good overview of Traffic Engineering in all
>    its aspects.  It seems a little over-wordy, I suspect it could be
>    edited down by 25% or more without loosing anything!

no action needed.

> 
>  * Section 3.2 (Measurement) is very good, giving a clear idea of why
>    one should measure, and what's involved in setting up a measurement
>    system as a component of Traffic Engineering.
> 
>  * Section 4 is a very good background covering pretty much everything
>    one needs to know about running a network!
> 
>  * The list of terms given in section 1.3 is also good, though some of
>    the terms have rather subtle shades of meaning in their Traffic
>    Engineering context.

No actions needed.

> 
>  * I'm a bit puzzled by the definition of 'micro-flow' which is
>    hidden under 'Traffic Flow.'  This says a micro-flow is a 5-tuple
>    (protocol, S/D addresses, S/D ports) plus a "bounded inter-arrival
>    time."  I think this is too open-ended to be useful, since it
>    depends on classifying packets into micro-flows depending on
>    whether or not they meet delay-variation criteria.

Removed "bounded inter-arrival time" constraint from traffic flow
definition.

>    You might like to forward the comments to the draft's editor?
>    And maybe I should join the tewg list and send the last comment 
>    above (the only 'technical' one) to the list??
> 
> - From IPPM chair Matt Zekauskas
> 
>   Section 4.5.5 is fine with me, accurate... but doesn't try 
> to stretch
>   & see if it would be appropriate with TEWG.  That is, I think that
>   the metrics could be used for TE purposes, not just for SLAs, but
>   it's possible TE might need something additional.  So, it's a bit
>   narrow, but accurate.
> 
>   I've only skimmed things... 'cause I'm leaving for Lithuania
> momentarily.
>   So, I've read 4.5.5, and 3.2 (also says lots of true things without
>   adding any TE insight).

No actions needed.

> 
> - From Diffserv chair (Brian Carpenter), regarding section 4.5.3.
> 
>   It's good. It would be slightly better if the last paragraph was
>   extended slightly:
> 
>   The concept of Per Domain Behaviors has been introduced to better
>   capture the notion of differentiated services across a complete
>   domain [RFC-3086].

done.

Cheers,
/Dan