Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
Hi, My reading of this thread of comments is that there is no reason to change anything regarding the document. I will therefore progress this document towards approval. Regards Magnus Westerlund Brian E Carpenter skrev: On 2007-10-05 05:38, ken carlberg wrote: I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) I would be concerned if outside groups spent time arguing foo is bad, or if they advocated other positions to the same issue. But I tend to feel quite uncomfortable with litmus tests based on inactivity of other groups/people. My personal view is that advocates of that line of reasoning place a bigger burden on themselves in providing specific in-depth arguments. Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. i appreciate work that is trivial because its generally simple, easy to accomplish, and leads to fewer interoperability issues. as for ISPs, its fascinating the disparity of how quiet and talkative they are depending on what side of the NDA you are on :-) In any case, if Pekka is correct, that's *exactly* why this draft and RFC 4594 are needed - to lay a minimum foundation on which ISPs can build operational practices and SLAs. It's always been clear to me that voice and video would be the main drivers for uptake of diffserv, and Marshall's comments confirm that. As that type of traffic grows, ISPs won't have any choice. Guidnace from the IETF seems entirely appropriate. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Magnus Westerlund IETF Transport Area Director TSVWG Chair -- Multimedia Technologies, Ericsson Research EAB/TVM/M -- Ericsson AB| Phone +46 8 4048287 Torshamsgatan 23 | Fax +46 8 7575550 S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED] -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Tue, 2 Oct 2007, ken carlberg wrote: On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. could you expand on this observation? I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Oct 4, 2007, at 2:35 AM, Pekka Savola wrote: On Tue, 2 Oct 2007, ken carlberg wrote: On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. could you expand on this observation? I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. Dear Pekka; FWIW, in the video conferencing world, DiffServe QOS is ubiquitous. (This is pretty frequently over internetworks, but not generally over the Internet.) The same is true for IPTV, but of course this is not yet internetwork much. I would rate it as too simple and too deployed for NANOG. Regards Marshall -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) I would be concerned if outside groups spent time arguing foo is bad, or if they advocated other positions to the same issue. But I tend to feel quite uncomfortable with litmus tests based on inactivity of other groups/people. My personal view is that advocates of that line of reasoning place a bigger burden on themselves in providing specific in-depth arguments. Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. i appreciate work that is trivial because its generally simple, easy to accomplish, and leads to fewer interoperability issues. as for ISPs, its fascinating the disparity of how quiet and talkative they are depending on what side of the NDA you are on :-) cheers, -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On 2007-10-05 05:38, ken carlberg wrote: I don't recall when was the last (Diffserv-based) QoS talk at NANOG or similar operator-rich meeting. (Sure, there is the tutorial, but it doesn't count.) I would be concerned if outside groups spent time arguing foo is bad, or if they advocated other positions to the same issue. But I tend to feel quite uncomfortable with litmus tests based on inactivity of other groups/people. My personal view is that advocates of that line of reasoning place a bigger burden on themselves in providing specific in-depth arguments. Seems like a potential indication that most typical ISPs aren't working on or interested in this, this stuff is so trivial, or that coordination is not necessary. i appreciate work that is trivial because its generally simple, easy to accomplish, and leads to fewer interoperability issues. as for ISPs, its fascinating the disparity of how quiet and talkative they are depending on what side of the NDA you are on :-) In any case, if Pekka is correct, that's *exactly* why this draft and RFC 4594 are needed - to lay a minimum foundation on which ISPs can build operational practices and SLAs. It's always been clear to me that voice and video would be the main drivers for uptake of diffserv, and Marshall's comments confirm that. As that type of traffic grows, ISPs won't have any choice. Guidnace from the IETF seems entirely appropriate. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Mon, 1 Oct 2007, The IESG wrote: The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Aggregation of DiffServ Service Classes ' draft-ietf-tsvwg-diffserv-class-aggr-04.txt as an Informational RFC DiffServ Pool 1 codepoints require Standards Action [1]. While this document doesn't define new ones (because there aren't any), it defines how one should configure the treatment for each and every Pool 1 codepoint in the network. Therefore in spirit it specifies DSCP codepoint behaviour and how those should be used. As such I believe this document is inappropriate as an Informational RFC. It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. If this work were to proceed, I suggest that first RFC 4594, which this document builds on, would attain IETF consensus by following the standards process for publication as a BCP. [1] http://www.iana.org/assignments/dscp-registry -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Tsvwg] Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
On Oct 2, 2007, at 10:11 AM, Pekka Savola wrote: It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. could you expand on this observation? -ken ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
Pekka, [FYI I've already indicated my support for this draft in a message sent to the IESG.] On 2007-10-03 03:11, Pekka Savola wrote: On Mon, 1 Oct 2007, The IESG wrote: The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Aggregation of DiffServ Service Classes ' draft-ietf-tsvwg-diffserv-class-aggr-04.txt as an Informational RFC DiffServ Pool 1 codepoints require Standards Action [1]. While this document doesn't define new ones (because there aren't any), it defines how one should configure the treatment for each and every Pool 1 codepoint in the network. Therefore in spirit it specifies DSCP codepoint behaviour and how those should be used. I think this is really not a valid interpretation. It's very common in the IETF to produce the first version of operational recommendations as Informational, with the possibility of producing a later version as BCP when there's successful operational experience. I believe that this draft, and RFC 4594, are in that category. IMHO they do not significantly change the implementation requirements for the various Proposed Standard diffserv PHBs; they add configuration recommendations for those PHBs, which is a perfectly legitimate thing for an Informational RFC. To be clear, the notion of reclassifying diffserv traffic at a domain boundary is a fundamental part of the diffserv architecture, and remapping diffserv classes into treatment aggregates, as this draft describes, is just an example of such reclassification. This draft does not change the diffserv architecture and does not redefine any of the standards track PHBs. To quote an example from the text: Traffic in the Real Time treatment aggregate should be carried in a common queue or class with a PHB as described in RFC 3246 [11] and RFC 3247 [12]. As such I believe this document is inappropriate as an Informational RFC. It is not clear that consensus in the IETF and deployments is strong enough to approve/recommend any specific treatment for standards track DSCP values. If this work were to proceed, I suggest that first RFC 4594, which this document builds on, would attain IETF consensus by following the standards process for publication as a BCP. Not until there is significant operational feedback, which is still a year or three in the future. I don't see that this draft, or RFC 4594, is significantly different in that respect from, say, RFC 4472. Brian [1] http://www.iana.org/assignments/dscp-registry ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-tsvwg-diffserv-class-aggr (Aggregation of DiffServ Service Classes) to Informational RFC
The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Aggregation of DiffServ Service Classes ' draft-ietf-tsvwg-diffserv-class-aggr-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2007-10-15. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-diffserv-class-aggr-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=14993rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
