Re: [tsvwg] Draft diffuser to QCI v04 posted

["Gengxuesong (Geng Xuesong)" <[e-mail]>]

Hi Jerome,

Thank you for your work. I think it is especially  useful for 5G deployment.
I notice that in the previous email, the scenario of ”carrier to carrier interconnect” seems to be excluded from the scope of the document. If I understand this right, the “carrier to carrier interconnect” here means that the RAN or CN belongs to one carrier and the TN belongs to another carrier. I think this is the most general use case for “QCI/5QI and DSCP mapping” . Considering that this draft is supposed to be “informational”, I think there is no harm to include this scenario in the draft at this stage ☺

Best Regards
Xuesong

From: tsvwg [mailto:[e-mail]] On Behalf Of Jerome Henry (jerhenry)
Sent: Tuesday, April 14, 2020 2:01 AM
To: tsvwg <[e-mail]>
Subject: [tsvwg] Draft diffuser to QCI v04 posted

Dear tsvwg,

Following our interim meeting last week, we posted an updated version of draft-diffserv-to-qci (https://datatracker.ietf.org/doc/draft-henry-tsvwg-diffserv-to-qci/).
This version integrates the feedback that was shared during the interim meeting (formatting error on one table, clarification that no IANA action was mandated).

We discussed extensively on thoughts that were shared during the interim meeting. We had also noticed that several groups had proposed DSCP values for QCI labels. ATIS was named specifically, but other organizations (e.g. NGMN) have proposed such maps. However, we found that the maps available were reflective of a specific point in time, and specific focus. As such, most mapping proposals only consider a small subset of the possible QCIs defined today, and also solely focus on a specific context (which, in the examples above, is typically Carrier to Carrier interconnect). We do not think that these actors need an IETF proposal to decide on how they should mark traffic that they exchange, and such interconnect is better defined in professional settings between Carriers.
By contrast, enterprises that implement dual path (Diffserv on one side, 3GPP on the other) for their UEs are in need of wanting to align their Diffserv markings and treatment to those they have agreed upon with their Carrier, thus creating a requirement different from the above. It seems to us that this draft can help propose such map. Dynamic negotiation (e.g. a-la-RFC 8100) and exchanges (a-la- draft-knoll-idr-qos-attribute-24) are undoubtedly very promising ways of implementing a QoS marking dialog at the interconnection point, but in a world where 3GPP has defined close to 30 traffic types, it seems that there is still a need for us (IETF) to propose a way to express these intents into Diffserv.

We are looking forward to receiving additional feedback on this version.

Best

Jerome