[tsvwg] Diffserv for interconnection and RFC 5127

["Black, David" <[e-mail]>]

Ruediger,

<WG co-chair hat on>

> thanks. I submitted a draft on the issue and I'm also involved in
> the ITU liaision.
> 
> Yes, to me IETF should pick up the subject of limited and "well
> enough defined" set of interconnection QoS classes.

Thanks - this is a quick response to add clarity on RFC 5127:

> I've reread RFC 5127. If it stays informational, I got no qualms
> with it. If a revised version of RFC 5127 is to be put on standards
> track, some parts of it must be better explained and possibly
> rewritten. If it is not touched, some parts of what is required
> in a revised 5127 from my point of view should become part of the
> interconnection work.

All three of the above options (revise RFC 5127 as Informational,
revise RFC 5127 as Standards Track, write a new RFC that could be
informational or standards track) are possibilities for this proposed
Diffserv interconnection work.

In addition, the proposed Diffserv Classes work involves both
RFC 4594 and RFC 5127 (the aggregations in 5127 would need to be
updated to reflect updates to the classes in 4594), but that
coupling does not dictate how the Diffserv interconnection work
should be done.  In particular, a new RFC for Diffserv interconnection
in addition to an update to RFC 5127 as part of the Diffserv Classes
work is a possible approach.

Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Monday, November 26, 2012 3:30 AM
> To: Black, David
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: RE: Diffserv for interconnection
> 
> David,
> 
> thanks. I submitted a draft on the issue and I'm also involved in the ITU liaision.
> 
> Yes, to me IETF should pick up the subject of limited and "well enough defined"
> set of interconnection QoS classes.
> 
> I've reread RFC5127. If it stays informational, I got no qualms with it. If a revised
> version of RFC5127 ist to be put on standards track, some parts of it must be
> better explained and possibly rewritten. If it is not touched, some parts of what
> is required in a revised 5127 from my point of view should become part of the
> interconnection work.
> 
> I'm halfway through http://tools.ietf.org/html/rfc5160 and the authors asked how I'd
> position my proposal with regard it. It is a more abstract document about
> inter provider QoS agreements. So far I think, RFC5160 and the proposals of my
> draft would complement each other.
> 
> Regards,
> 
> Rüdiger
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Black, David
> Sent: Saturday, November 24, 2012 11:51 PM
> To: [e-mail]
> Subject: [tsvwg] Diffserv for interconnection
> 
> Hello - this is your new tsvwg co-chair again, with <co-chair hat on>.
> 
> The Atlanta tsvwg minutes are at:
>         http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg
> 
> This message is about my second action item, on use of Diffserv for
> network interconnection.
> 
> Excerpt from the minutes (explanation below):
> ---------------
> Topic: interconnect liaison with ITU-T
> - (James Polk) describing set of code points (?) for the interconnection
>         of core providers.
> - (Gorry Fairhurst) asks if we should make a new set of recommendations for
>         a particular interface.
> - (David Black) thinks we should. As Chair, he asks the room if we should
>         work on this?  The room (by show of hands) indicates yes.
>         So we'll put this on the list
> (Joel Halpern)  thinks we don't need to do anymore at this meeting.  We
>         should state "this is an interesting problem, and we should do
>         something about this"
> ---------------
> 
> So the immediate question is what was "this" in Joel's comment?
> 
> The short answer is that it's slide 6 in this set of slides:
>         http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-8.pdf
> 
> The rationale for doing "this" is also on that slide - it's basically
> scaling/reuse of configuration, so that a carrier or operator can apply
> a single diffserv configuration to interconnections with multiple other
> networks.  Also see draft-geib-tsvwg-diffserv-intercon-00 .
> 
> The item that I recall asking about was whether the IETF should work on a
> single set of recommended diffserv behavior (PHBs) and codepoints (DSCPs)
> for use in carrier interconnection?
> 
> The sense of the room in Atlanta (as noted in the minutes) was that the
> IETF should work on this, with details of how to do that TBD - in
> particular there was no assumption about the relationship of this work
> to RFC 5127 on aggregation of Diffserv Classes (e.g., if undertaken,
> this new work may or may not be carried out by revising RFC 5127).
> 
> If anyone disagrees with the sense of the room in Atlanta, now would
> be a good time to speak up.
> 
> If the sense of the room in Atlanta is confirmed, the next action is
> for me to work through the ITU-T SG12 liaison (primarily the draft of
> y.qosmap) and consult with Ruediger about what makes sense before
> bringing a proposal for what to do back to this list.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
>