Re: [tsvwg] Diffserv for interconnection

[<[e-mail]>]

Dear Ruediger,

Please see inline.

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De 
>la part de [e-mail]
>Envoyé : lundi 26 novembre 2012 09:30
>À : [e-mail]
>Cc : LEVIS Pierre OLNC/OLPS; [e-mail]; JACQUENET 
>Christian OLNC/OLN
>Objet : Re: [tsvwg] 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. 

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
>draft would complement each other.

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 ;-)?

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