Re: [tsvwg] Diffserv for interconnection

[<[e-mail]>]

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