[tsvwg] Diffserv for interconnection

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

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]
----------------------------------------------------