Re: [tsvwg] 答复: Draft diffuser to QCI v04 posted

"Jerome Henry (jerhenry)" <jerhenry@cisco.com> Tue, 14 April 2020 22:06 UTC

Return-Path: <jerhenry@cisco.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754303A1130 for <tsvwg@ietfa.amsl.com>; Tue, 14 Apr 2020 15:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JsXiGXVV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YcPGXfu6
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETwmdJ09Zown for <tsvwg@ietfa.amsl.com>; Tue, 14 Apr 2020 15:06:09 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCBD53A112F for <tsvwg@ietf.org>; Tue, 14 Apr 2020 15:06:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46485; q=dns/txt; s=iport; t=1586901968; x=1588111568; h=from:to:subject:date:message-id:mime-version; bh=ZUu1j3gCXnHKug/K4X20YK3ZUwEIHAt8cCTqLfTPs7c=; b=JsXiGXVVxodD3h4iWMs5AafatOVE9fM/TsJ6nq9vBszxGigzGINnBzlf FocPylompKIj3yx3Qf4JCnE2ZfBgFI2ViChvC3ehgLpjuE4/rZMKHsFK5 rwZmsrP/MK7NXiVMOoxVXAHwoocv2pak5FWEs+rtRaScxKrp+gQTi7Eda o=;
IronPort-PHdr: 9a23:ESvSJhOpZrHdcpBUnTcl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBj5IeTqYiogDexJVURu+DewNk0GUMs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DxAADrMpZe/4kNJK1mHQEBAQkBEQUFAYFnCAELAYEkL1AFbFggBAsqCoQSg0YDhFmGDk6CEZgjgS4UgRADVAoBAQEMAQEjCgIEAQGERAIXgWwkNAkOAgMBAQsBAQUBAQECAQUEbYVWDIVwAQECAgESER0BASUNBgQNAQYCEQMBAQEhAQYDAgQwFAYDCgQBEiKDBAGBfk0DDiABDpM2kGcCgTmIYnWBMoJ/AQEFgUZBgxwYgg4DBoE4AYJhiVMagUE/gREnHIFPUC4+gmcCAgEBgScFARIBOAkNCYJcMoIsjjoOglKGCpk8ewqCQod+ii6FJBYHgwaZI4Nji3CJMpMYAgQCBAUCDgEBBYFSOWdwcBVlAYI+UBgNmg9TghmBB4UUhUF0AoEnjQcBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.72,384,1580774400"; d="scan'208,217";a="738855440"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Apr 2020 22:06:07 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 03EM67EK004562 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Apr 2020 22:06:07 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Apr 2020 17:06:07 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Apr 2020 18:06:06 -0400
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 14 Apr 2020 17:06:06 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MZtnGj8o0C/hPONcTRMGnOmQaeN8w4LinbIOCguizo8cY1XClXReSTN/Oa0I5ypnl8TCSptWe3AdqwVxAM5hKMm1bZUm6TkpQVPWWQ7vn/24zvGQu5D/rBaaTqg108yPmKr1A1UOTJ2Mc4wT/hkX5iTbKYmy70aV4Rbw4ApYVo1bbqMsqHZGRYAC4diNb+dMUjfDFFaSW3IrYddumjC05hiWxfMmdCIJWA1eFHH6JITSCnieSIXV6aRNT7Np4Y/U0g24uFV3U0pYFLolP6qFYkBKdAmSm0uIXeUbG658N4Zn4kdosGbdeZP6i4sz0UQWu4cfBZs6DoXw7AVz69Wzrw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZUu1j3gCXnHKug/K4X20YK3ZUwEIHAt8cCTqLfTPs7c=; b=BKWGgdlOkFM0LuBlG/8308PH1VhUxKmvytRdZieOPIVF1BLLL4fU6Wl4jZ+2Vu3liZs/8o+KMxUqlSfpP3oQEd6saWJ2VzMnyypu+xe2jh1ceRMVfXnkmyMQPVxpq3Oy6uFDYoAwCaTHs50LvoVe/37k7n5QRGkHjU3p1T7fcxuwCKu31rUTmCiAUi8o8OILVIPo7dIA2sWVZWXP9KppNyRogQGA+IGxtdiSQr2Lz9qNmDunVXvgrh9ceLKxLuKMPzlTlxDi+cHcsORfLs+3XJniGDnmfZHGu9yNpZQ1/1wT+hk0IJn7KpCcAGoWhQTWerqRhz0sxCTwgCpjg+msMA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZUu1j3gCXnHKug/K4X20YK3ZUwEIHAt8cCTqLfTPs7c=; b=YcPGXfu6/7japVs0WiCGwqBC+jAZOHndr8j2LLhO/7Aox0wBYbJtsM32cbEymzJ9le1gct2ZO7Q7Ke9rF0T61sQg3VUAPRPTMx8cUojZB9mj9CE1v/4YoUFuVPBlAGR6MmCXf9MiZeRn9qE1skgGj8a5ko4xGhi/FEjYZ9dkEZ0=
Received: from DM6PR11MB3899.namprd11.prod.outlook.com (2603:10b6:5:19c::31) by DM6PR11MB2633.namprd11.prod.outlook.com (2603:10b6:5:c0::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.28; Tue, 14 Apr 2020 22:06:04 +0000
Received: from DM6PR11MB3899.namprd11.prod.outlook.com ([fe80::c8ff:97a4:c5ca:4072]) by DM6PR11MB3899.namprd11.prod.outlook.com ([fe80::c8ff:97a4:c5ca:4072%7]) with mapi id 15.20.2900.028; Tue, 14 Apr 2020 22:06:05 +0000
From: "Jerome Henry (jerhenry)" <jerhenry@cisco.com>
To: "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>, "Black, David" <David.Black@dell.com>, "Jerome Henry (jerhenry)" <jerhenry=40cisco.com@dmarc.ietf.org>, tsvwg <tsvwg@ietf.org>
Thread-Topic: [tsvwg] 答复: Draft diffuser to QCI v04 posted
Thread-Index: AQHWEqjkAdqGMQBepEyfKGOwaLcmMQ==
Date: Tue, 14 Apr 2020 22:06:04 +0000
Message-ID: <E669B027-A912-46DF-B338-EABA41A44907@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.36.20041300
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jerhenry@cisco.com;
x-originating-ip: [173.38.117.81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f7565349-150d-4e68-35ec-08d7e0c006e5
x-ms-traffictypediagnostic: DM6PR11MB2633:
x-microsoft-antispam-prvs: <DM6PR11MB26337AD49C438C9E96D2A5A2D5DA0@DM6PR11MB2633.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0373D94D15
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3899.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(376002)(396003)(39850400004)(136003)(366004)(91956017)(8936002)(6512007)(66446008)(6486002)(64756008)(186003)(26005)(316002)(6506007)(66556008)(110136005)(66476007)(53546011)(2616005)(66946007)(2906002)(33656002)(224303003)(76116006)(478600001)(36756003)(5660300002)(86362001)(81156014)(71200400001); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: eHkAfVJQ8zMRLPVpaXxKTKnZHv49HpzryS5GnfL6jtsccJYBg0yljQ66zKN61f/gSxspWdHG2Nq/ZDd4JriPABy6VHnoXszx693h6ux09U09+8wflC03KY1XPlCy1tk4zo1ES8Q/ux5RX9GGex/SoLQuWJkUzevN68E1gtOYIn9u+qiL2yEtIcVY9Puo9EETLMNI80s02/o/YICWl5tc1/i10zszqSU/1Qe1EbjOzYB2oTyRFfVMY/ARAEYo9vo88FU1uyR11Fv5FlhzSsdH+oCgQU559DO74o4G8aFmTpRAEz3/yRacFyhz+Tb7+/XKjR5Uk/t/g3M0rfQgGpYA8RmRmuAkyq3UjuY+w3wgTusqmoHeV0KUY4Zy39y15/8H2Pta2CtqKSEu2BC4T7LvQMY4dmZOO4baCun8vdKlu7cyeQoJANTuFsz/lGKWHNwRGgjAWxjZ5I0RlatLR/DQcGm7WXPD5p7VO+OKX2STlxewP9jj0+hSGWdixYWyiZ8CjALh0KC1EOoX6da6bFFhBQ==
x-ms-exchange-antispam-messagedata: y1kpl6F6ZX6Yomv/Hzp/oMdjE7z8jKS4am6AAzQ20Lh1fpFHFB7Vw8nqD1xTy6r7DmdcVBukVlhmEMs+dZSY3AEgRz1Cv7jMalZ5NRpBIK0InO3XyPeMKCQSj0Ljogy63fz8RQpY/CTPddDdsWGZMA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_E669B027A91246DFB338EABA41A44907ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f7565349-150d-4e68-35ec-08d7e0c006e5
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2020 22:06:04.8872 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: CoEODLlpDrmxRpsYB6NJwXlwBiVfisKZ70p3Js5E6xj9a/a9K1hmNtTZlGtXYpLKXTPb1hTYZQ4oDOE0MjrC1A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2633
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/5bILgZZOfjKrMfWEhy8cf7IoXUs>
Subject: Re: [tsvwg] 答复: Draft diffuser to QCI v04 posted
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2020 22:06:14 -0000

Thank you Xuesong,

We talked a lot informally to various people working in the development of 3GPP Standards. This was useful in the beginning, to better guide our understanding of the intent of each QCI. Then, when the draft was shared in the tsvwg, people familiar with 3GPP work were also friendly enough to remind us that carrier interconnect operations are decided in other forums, for example GSMA and probably others. Maybe this work will be useful to them (and maybe not), time will tell. They probably do not need this work to decide of an interconnect mapping need and solve it if it presents itself. Maybe our conclusion on mapping can be useful if they decide that such work is needed, but our scope is more on the Diffserv side.
I also agree with you that, besides a mapping conclusion, we may also find that we should (in the IETF) define new traffic types. It seems that with VR and IoT, new flows are appearing that do not fit well in our current model.

My 2 cents


Take care

Jerome

From: tsvwg <tsvwg-bounces@ietf.org> on behalf of "Gengxuesong (Geng Xuesong)" <gengxuesong@huawei.com>
Date: Tuesday, April 14, 2020 at 5:11 PM
To: "Black, David" <David.Black@dell.com>, "Jerome Henry (jerhenry)" <jerhenry=40cisco.com@dmarc.ietf.org>, tsvwg <tsvwg@ietf.org>
Subject: [tsvwg] 答复: Draft diffuser to QCI v04 posted

Hi David,

I agree that direct feedback from 3GPP people is very helpful. However, I still think it will be great, at some stage, to have an official liaison to make this work more solid.
And, I’m wondering maybe we will have some very interesting conclusion from this draft, for example some new DSCPs may be needed to implement similar QoS intend as QCI/5QI does, which could also be very instructive in the scenario of “carrier to carrier interconnecting”.

Best Regards
Xuesong

发件人: Black, David [mailto:David.Black@dell.com]
发送时间: 2020年4月15日 2:56
收件人: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com>; Jerome Henry (jerhenry) <jerhenry=40cisco.com@dmarc.ietf.org>; tsvwg <tsvwg@ietf.org>
抄送: Black, David <David.Black@dell.com>
主题: RE: Draft diffuser to QCI v04 posted

Hi Xuesong,

We’ve not needed to resort to exchanging liaison statements ... at least not yet.  There were some very productive conversations with 3GPP folks back at IETF 105 in Montreal, which were the source of some of the guidance that I’ve passed along here.   We (WG chairs) will have to see what we can do in the absence of in-person IETF meeting weeks.

Thanks, --David

From: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>
Sent: Tuesday, April 14, 2020 12:21 PM
To: Black, David; Jerome Henry (jerhenry); tsvwg
Subject: 答复: Draft diffuser to QCI v04 posted


[EXTERNAL EMAIL]
Hi David,

Thank you for your explanation. I agree that we should hear the voice from 3GPP. I’m not quite familiar with the procedure, but I am wondering will we have a liaison to discuss this issue and get to some agreement between 3GPP and IETF formally? (or we maybe we already have?)

Best Regards
Xuesong


发件人: Black, David [mailto:David.Black@dell.com]
发送时间: 2020年4月14日 22:26
收件人: Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com<mailto:gengxuesong@huawei.com>>; Jerome Henry (jerhenry) <jerhenry=40cisco.com@dmarc.ietf.org<mailto:jerhenry=40cisco.com@dmarc.ietf.org>>; tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
抄送: Black, David <David.Black@dell.com<mailto:David.Black@dell.com>>
主题: RE: Draft diffuser to QCI v04 posted

Hi Xuesong,

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

Among the relevant considerations is that RFC 4594 (Diffserv Service Classes) is Informational, but has had sufficient adoption to be viewed as a de facto standard by some.  The TSVWG chairs have had a number of discussions with 3GPP participants/representatives, and would want to ensure that covering this use case (even in an Informational document) is acceptable to 3GPP before including that use case in a draft that the WG adopts.  In those discussions, we have heard strong 3GPP objections to the IETF advising large mobile carriers on interconnections among themselves, or as Jerome writes:

>> We do not think that these actors [large Carriers] 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.

Thanks, --David (TSVWG co-chair)

From: tsvwg <tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>> On Behalf Of Gengxuesong (Geng Xuesong)
Sent: Monday, April 13, 2020 11:44 PM
To: Jerome Henry (jerhenry); tsvwg
Subject: Re: [tsvwg] Draft diffuser to QCI v04 posted


[EXTERNAL EMAIL]
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:tsvwg-bounces@ietf.org] On Behalf Of Jerome Henry (jerhenry)
Sent: Tuesday, April 14, 2020 2:01 AM
To: tsvwg <tsvwg@ietf.org<mailto:tsvwg@ietf.org>>
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