Subject: [tsvwg] Diffserv for interconnection

From: "Black, David" <[email-masked]>
Date: Sat, 24 Nov 2012 17:51:19 -0500

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: <[email-masked]>
Date: Mon, 26 Nov 2012 09:30:00 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of Black, David
Sent: Saturday, November 24, 2012 11:51 PM
To: [email-masked]
Subject: [tsvwg] Diffserv for interconnection

Thanks,
--David

---

From: <[email-masked]>
Date: Mon, 26 Nov 2012 11:22:48 +0100

Dear Ruediger,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de [email-masked]
>Envoyé : lundi 26 novembre 2012 09:30
>À : [email-masked]
>Cc : LEVIS Pierre OLNC/OLPS; [email-masked]; JACQUENET 
>Christian OLNC/OLN
>Objet : Re: [tsvwg] Diffserv for interconnection
>
>David,
>
>inter provider QoS agreements. 

Med: FWIW, the rationale we adopted in RFC5160 is as follows:

* Network Providers are free to define their own traffic engineering policies and their QoS class of services in their domains.
* Diffserv is only a means among other to achieve differentiated forwarding
* The number and the definition of QoS classes is not universal
* Network Providers are not obliged to expose their internal class of services to external parties
* When extending some QoS classes beyond the boundaries of a given domain, it is required to establish contractual agreements between network providers, otherwise the traffic will be handed as BE.
* These agreements will be the place where class identification is discussed and agreed.
* Remarking is likely to be always enforced in both exit border router and entry border router: local class of services are not advertised outside the domain.
* Providers need a tool to help deciding how to bind one/multiple local QoS classes with adjacent class of service: hence the concept of meta-QoS-Class.
* CoS identifier is not sufficient to provide QoS: additional parameters are to be agreed between network providers. Examples of these parameters are: constraints on the traffic (eg., tcp-friendly), network resources for the class / overall traffic using this class, etc.

So far I think, RFC5160 and the 
>proposals of my

Med: Agreed. I personally see a value in standardizing a very limited set of interconnection classes. In addition to the interconnection class name/identifier discussion point, it is important also to have a detailed definition of the class itself (in terms of attributes, target services, traffic conditions, etc.). Perhaps, try the http://tools.ietf.org/html/rfc3086#section-8 ;-)?

---

From: "Black, David" <[email-masked]>
Date: Mon, 26 Nov 2012 14:52:24 -0500

Ruediger,

<WG co-chair hat on>

> 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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, November 26, 2012 3:30 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Diffserv for interconnection
> 
> David,
>