From chelai@cisco.com Fri Feb 8 19:00:55 2013 Return-Path: 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 F0E4921F8C5C for ; Fri, 8 Feb 2013 19:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCdZ6Cc-B0wU for ; Fri, 8 Feb 2013 19:00:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1B94421F8C59 for ; Fri, 8 Feb 2013 19:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2978; q=dns/txt; s=iport; t=1360378851; x=1361588451; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=oiBnxRMHYte5w9700cGGBW2Yx9E6Emo7ie0F/ZFfN5Y=; b=G1v7PqQTfGA++IBUjaJjrfF66xQlely5Qoid+nsLjoPaT428lZEiUNqN +6WZIncmJixl44GjvCyGJX9WTINIWdAXzSIU8kZ64Kg3jo1hcL+7h73EH UAM/Fyyu/MK4yHjHRRooshTiRzDvxsqRGQRdY6J+GpkIkZEGyuhXFGPtZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAMi6FVGtJXHA/2dsb2JhbABFhk25TX0Wc4IfAQEBBCMRMRICDAYBCBEEAQEDAgYdAwIEMBQBBgEBBQQBBA4FCAGICAysQJI6gSOPJjJhA5dBjzaDAIIk X-IronPort-AV: E=Sophos;i="4.84,632,1355097600"; d="scan'208";a="175123193" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 09 Feb 2013 03:00:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1930okg013991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 9 Feb 2013 03:00:50 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.98]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 8 Feb 2013 21:00:49 -0600 From: "Cheng-Jia Lai (chelai)" To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-lai-tsvwg-normalizer-00.txt Thread-Index: Ac4GcBXrNOtmIMweTbifdbQEwQJH6Q== Date: Sat, 9 Feb 2013 03:00:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.140] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Wenyi Wang \(wenywang\)" , "Stan Yang \(stanyang\)" , "Toerless Eckert \(eckert\)" , "Fred Yip \(fyip\)" Subject: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalizer-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 03:00:55 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBJbnRlcm5ldCBkcmFmdCB0byBkZXNj cmliZSBhIE5vcm1hbGl6YXRpb24gTWFya2VyIChOTSkgZm9yIERpZmZTZXJ2IEFGIFBIQiBncm91 cHMsIGJhc2VkIG9uIG91ciB3b3JrIGF0IENpc2NvLiBUaGUgZ29hbCBvZiBOTSBkZXBsb3ltZW50 IGlzIHRvIGNyZWF0ZSBhIG5ldyBpbmNlbnRpdmUgZm9yIHZpZGVvIGVuY29kZXJzIHRvIGdlbmVy YXRlIG1vcmUgZGlzY2FyZGFibGUgcGFja2V0cyB3aGVuIHVzaW5nIEFGIFBIQiBpbiBESWZmU2Vy di4gV2UgYXJlIGxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIHJldmlldyBjb21tZW50cy4NCg0KQmVz dCByZWdhcmRzLA0KQ0oNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDA4LCAyMDEzIDY6MjUgUE0NClRvOiBDaGVuZy1KaWEgTGFp IChjaGVsYWkpDQpDYzogV2VueWkgV2FuZyAod2VueXdhbmcpOyBTdGFuIFlhbmcgKHN0YW55YW5n KTsgVG9lcmxlc3MgRWNrZXJ0IChlY2tlcnQpOyBGcmVkIFlpcCAoZnlpcCkNClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXItMDAu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxhaS10c3Z3Zy1ub3JtYWxpemVy LTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaGVuZy1KaWEgTGFp IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQt bGFpLXRzdndnLW5vcm1hbGl6ZXINClJldmlzaW9uOgkgMDANClRpdGxlOgkJIE5vcm1hbGl6YXRp b24gTWFya2VyIGZvciBBRiBQSEIgR3JvdXAgaW4gRGlmZlNlcnYNCkNyZWF0aW9uIGRhdGU6CSAy MDEzLTAyLTA4DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdl czogMTUNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXItMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXIN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGFpLXRz dndnLW5vcm1hbGl6ZXItMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgbWVtbyBkZXNjcmliZXMg YSBOb3JtYWxpemF0aW9uIE1hcmtlciAoTk0pIGF0IERpZmZTZXJ2IChEUykNCiAgIG5vZGVzIHRv IG5vcm1hbGl6ZSB0aGUgZGlzdHJpYnV0aW9uIG9mIERTIGNvZGVwb2ludCAoRFNDUCkgbWFya2lu Z3MNCiAgIGZvciBhbiBBc3N1cmVkIEZvcndhcmRpbmcgKEFGKSBQZXItSG9wIEJlaGF2aW9yIChQ SEIpIGdyb3VwLiAgTk0gaXMNCiAgIHVzZWZ1bCBmb3IgdHJhZmZpYyBjb25kaXRpb25pbmcgd2l0 aCBBY3RpdmUgUXVldWUgTWFuYWdlbWVudCAoQVFNKQ0KICAgd2hlbiB0aGUgQUYgUEhCIGdyb3Vw IGlzIGRlcGxveWVkIGZvciBtdWx0aW1lZGlhIHNlcnZpY2UgY2xhc3NlcyB0aGF0DQogICBjYXJy eSB2aWRlbyBwYWNrZXRzIHdpdGggYWR2YW5jZWQgY29kZWMgdGVjaG5vbG9naWVzLiAgVXNpbmcg Tk0gY2FuDQogICBvZmZlciBhbiBpbmNlbnRpdmUgdGhhdCBpcyBob3dldmVyIG1pc3NpbmcgaW4g dG9kYXkncyBlY29zeXN0ZW0gb2YNCiAgIHByYWN0aWNhbCBkZXBsb3ltZW50LCBpLmUuLCB3aGVu IGNvbmdlc3Rpb24gb2NjdXJzIGluIHRoZSBBRiBQSEINCiAgIGdyb3VwLCB0aGUgbmV0d29yayBz aG91bGQgYWxsb3cgYSB2aWRlbyBjb2RlYyB0byBiZW5lZml0IGZyb20gaXRzDQogICBlZmZvcnQg b2YgZ2VuZXJhdGluZyBmaW5lciBsYXllcnMgb2YgaW50cmEtZmxvdyBwcmVjZWRlbmNlIChJRlAp IHdpdGgNCiAgIGRpc2NhcmRhYmxlIHBhY2tldHMgaW4gYSBtb3JlIGJhbGFuY2VkIGRpc3RyaWJ1 dGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFy aWF0DQoNCg== From lucy.yong@huawei.com Tue Feb 12 08:24:12 2013 Return-Path: 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 DC90321F8F69 for ; Tue, 12 Feb 2013 08:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.799 X-Spam-Level: X-Spam-Status: No, score=-6.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0484keP6myKE for ; Tue, 12 Feb 2013 08:24:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7CC21F8F61 for ; Tue, 12 Feb 2013 08:24:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOJ93386; Tue, 12 Feb 2013 16:24:10 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Feb 2013 16:23:50 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 00:24:09 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Tue, 12 Feb 2013 08:23:58 -0800 From: Lucy yong To: "tsvwg@ietf.org" Thread-Topic: New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: AQHOCTyx7lnn4u8kTUuXQKMJUMyph5h2Z8Kg Date: Tue, 12 Feb 2013 16:23:57 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.73] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Xuxiaohu Subject: [tsvwg] FW: New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:24:13 -0000 UGxlYXNlIHNlZSBiZWxvdyBhbmQgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCkx1Y3kNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFR1ZXNkYXksIEZl YnJ1YXJ5IDEyLCAyMDEzIDEwOjE5IEFNDQo+IFRvOiBMdWN5IHlvbmcNCj4gQ2M6IFh1eGlhb2h1 DQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteW9uZy10c3Z3 Zy11ZHAtZW5jYXAtNC1pcC0NCj4gdHVubmVsaW5nLTAwLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC15b25nLXRzdndnLXVkcC1lbmNhcC00LWlwLXR1bm5lbGluZy0w MC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWN5IFlvbmcgYW5k IHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gRmlsZW5hbWU6CSBkcmFm dC15b25nLXRzdndnLXVkcC1lbmNhcC00LWlwLXR1bm5lbGluZw0KPiBSZXZpc2lvbjoJIDAwDQo+ IFRpdGxlOgkJIEdlbmVyaWMgVURQIEVuY2Fwc3VsYXRpb24gZm9yIElQIFR1bm5lbGluZw0KPiBD cmVhdGlvbiBkYXRlOgkgMjAxMy0wMi0xMg0KPiBXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCj4gTnVtYmVyIG9mIHBhZ2VzOiAxNA0KPiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXlvbmctdHN2d2ctDQo+IHVkcC1lbmNhcC00 LWlwLXR1bm5lbGluZy0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvbmctdHN2d2ctdWRwLQ0KPiBlbmNhcC00LWlwLXR1bm5l bGluZw0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXlvbmctdHN2d2ctdWRwLWVuY2FwLQ0KPiA0LWlwLXR1bm5lbGluZy0wMA0KPiANCj4gDQo+IEFi c3RyYWN0Og0KPiAgICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3IgZW5jYXBz dWxhdGluZyBuZXR3b3JrIGxheWVyDQo+ICAgIHByb3RvY29scyB3aXRoaW4gVURQIHN1Y2ggdGhh dCB0aGUgcGF5bG9hZCBwcm90b2NvbCBjYW4gYmUNCj4gICAgaWRlbnRpZmllZCBmcm9tIHRoZSBk ZXN0aW5hdGlvbiBwb3J0IHZhbHVlLiBUaGUgbWVjaGFuaXNtIGFsc28NCj4gICAgYWxsb3dzIGZv ciB0aGUgc291cmNlIHBvcnQgdG8gYmUgdXNlZCBhcyB0aGUgZW50cm9weSBmaWVsZCBmb3IgdGhl DQo+ICAgIHB1cnBvc2Ugb2YgbG9hZCBiYWxhbmNpbmcgaW4gZW52aXJvbm1lbnRzIHN1Y2ggYXMg RXF1YWwgQ29zdA0KPiAgICBNdWx0aXBhdGggKEVDTVApIGluIHRoZSB1bmRlcmx5aW5nIElQIG5l dHdvcmsuDQo+IA0KPiAgICBBcHBsaWNhdGlvbiBvZiB0aGlzIHRlY2huaXF1ZSBpcyBmb2N1c2Vk IG9uIHR1bm5lbGluZyBuZXR3b3JrDQo+ICAgIHByb3RvY29sIGZsb3dzIGFjcm9zcyBJUCBuZXR3 b3JrcyBpbiBlbnZpcm9ubWVudHMgd2hlcmUgbG9hZC0NCj4gICAgYmFsYW5jaW5nIGlzIHJlcXVp cmVkLiBObyBjaGFuZ2VzIHRvIHRoZSB1bmRlcmx5aW5nIElQIG5ldHdvcmsgb3INCj4gICAgdGhl IHBheWxvYWQgbmV0d29ya3MgYXJlIHJlcXVpcmVkLg0KPiANCj4gDQo+IA0KPiANCj4gVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0K From lars@netapp.com Tue Feb 12 08:46:55 2013 Return-Path: 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 1098621F8F6C for ; Tue, 12 Feb 2013 08:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.289 X-Spam-Level: X-Spam-Status: No, score=-10.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if8TUYu8cRcR for ; Tue, 12 Feb 2013 08:46:54 -0800 (PST) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8894C21F8F67 for ; Tue, 12 Feb 2013 08:46:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,650,1355126400"; d="scan'208";a="19954831" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx12-out.netapp.com with ESMTP; 12 Feb 2013 08:46:53 -0800 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1CGkqWO027461; Tue, 12 Feb 2013 08:46:53 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Tue, 12 Feb 2013 08:46:52 -0800 From: "Eggert, Lars" To: Lucy yong Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: AQHOCUCO6o7IeeV8aE2yX67nv/gfaA== Date: Tue, 12 Feb 2013 16:46:51 +0000 Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <380FFD38513CC74095A17B88D53855B4@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Xuxiaohu , "tsvwg@ietf.org" Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:46:55 -0000 Hi, On Feb 12, 2013, at 8:23, Lucy yong wrote: >> Filename: draft-yong-tsvwg-udp-encap-4-ip-tunneling why do you require IANA to register a block of port numbers? You could simp= ly use a block of private ports (> 49152) without registration. A lot of ot= her tunneling state will need to be configured; requiring to configure whic= h port block is used is just one more piece of information. Lars From lucy.yong@huawei.com Tue Feb 12 09:52:13 2013 Return-Path: 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 1548E21F8FD5 for ; Tue, 12 Feb 2013 09:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.786 X-Spam-Level: X-Spam-Status: No, score=-6.786 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4VQeKdyP9u8 for ; Tue, 12 Feb 2013 09:52:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 806ED21F8FEF for ; Tue, 12 Feb 2013 09:52:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOJ98052; Tue, 12 Feb 2013 17:51:59 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Feb 2013 17:51:37 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 12 Feb 2013 17:51:56 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.007; Tue, 12 Feb 2013 09:51:46 -0800 From: Lucy yong To: "Eggert, Lars" Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: AQHOCUCXqJqOJl7UNUy1HBObveZhWZh2e2xw Date: Tue, 12 Feb 2013 17:51:45 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , 'John E Drake' , 'Edward Crabbe' , "tsvwg@ietf.org" , "'Carlos Pignataro \(cpignata\)'" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:52:13 -0000 X-List-Received-Date: Tue, 12 Feb 2013 17:52:13 -0000 Hi Lars, Thank you for the quick comments!=20 As mentioned in the document and you point out, a block of port numbers mak= e the implementation easier, e.g. may use of mask. Regarding IANA registry = or private ports, for vendor hardware interworking, it is better to standar= dize the port number for the payload types. IANA registry is the way to ach= ieve this. This is our suggestion and we would like to hear the opinions on= this. Since we have discussed this a lot among contributors, I include them in th= is thread in case that they are not a subscriber in this WG. Regards, Lucy > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Tuesday, February 12, 2013 10:47 AM > To: Lucy yong > Cc: tsvwg@ietf.org; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 > Hi, >=20 > On Feb 12, 2013, at 8:23, Lucy yong wrote: > >> Filename: draft-yong-tsvwg-udp-encap-4-ip-tunneling >=20 > why do you require IANA to register a block of port numbers? You could > simply use a block of private ports (> 49152) without registration. A > lot of other tunneling state will need to be configured; requiring to > configure which port block is used is just one more piece of > information. >=20 > Lars From adrian@olddog.co.uk Tue Feb 12 09:52:14 2013 Return-Path: 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 BA10D21F8FEF for ; Tue, 12 Feb 2013 09:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KkqGhCmfB8h for ; Tue, 12 Feb 2013 09:52:04 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id C877D21F8FE6 for ; Tue, 12 Feb 2013 09:51:59 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1CHptCq009551; Tue, 12 Feb 2013 17:51:55 GMT Received: from 950129200 (089144192054.atnat0001.highway.a1.net [89.144.192.54]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1CHprg8009543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Feb 2013 17:51:54 GMT From: "Adrian Farrel" To: "'Eggert, Lars'" , "'Lucy yong'" References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> In-Reply-To: Date: Tue, 12 Feb 2013 17:51:52 -0000 Message-ID: <037501ce0949$a4c6aef0$ee540cd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHLVK05VAwXbfafcwJxz95fvM9mpANbH2kBmGEPCiA= Content-Language: en-gb Cc: 'Xuxiaohu' , tsvwg@ietf.org Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:52:14 -0000 Hey Lars, The thought is that it is useful for interop that ports are registered. It is useful for implementations if all the ports used for this tunneling are contiguous (although that may be tenuous). It would be useful for future allocations for similar tunneling to be contiguous. However, the I-D does not ask to register a block of port numbers. It asks IANA to consider reserving further ports for future similar use. When you say "a lot of other tunneling state will need to be configured", what have you in mind? What tunneling state is currently configured to carry stuff in IP tunnels? Cheers, Adrian > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Eggert, Lars > Sent: 12 February 2013 16:47 > To: Lucy yong > Cc: Xuxiaohu; tsvwg@ietf.org > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4- > ip-tunneling-00.txt > > Hi, > > On Feb 12, 2013, at 8:23, Lucy yong wrote: > >> Filename: draft-yong-tsvwg-udp-encap-4-ip-tunneling > > why do you require IANA to register a block of port numbers? You could simply > use a block of private ports (> 49152) without registration. A lot of other tunneling > state will need to be configured; requiring to configure which port block is used is > just one more piece of information. > > Lars From Ruediger.Geib@telekom.de Tue Feb 12 23:31:23 2013 Return-Path: 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 4020821F8918 for ; Tue, 12 Feb 2013 23:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GEcZ4nmz+C7 for ; Tue, 12 Feb 2013 23:31:22 -0800 (PST) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 31D3A21F890E for ; Tue, 12 Feb 2013 23:31:20 -0800 (PST) Received: from he113657.emea1.cds.t-internal.com ([10.134.99.17]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 13 Feb 2013 08:31:18 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 13 Feb 2013 08:31:18 +0100 From: To: Date: Wed, 13 Feb 2013 08:31:16 +0100 Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: AQHOCUCXqJqOJl7UNUy1HBObveZhWZh2e2xwgADoeRA= Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: vishwas.manral@hp.com, jdrake@juniper.net, edc@google.com, tsvwg@ietf.org, cpignata@cisco.com, nsheth@contrailsystems.com, fanyb@gsta.com, Yiu_Lee@Cable.Comcast.com, xuxiaohu@huawei.com Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 07:31:23 -0000 Hi Lucy, as the draft only specifies tunnel ingress and egress behaviour, these node= s are identified and configured by an operator I guess. Further, the draft mentions DiffServ, but it doesn't mention ECN or Conex t= reatment. The latter two aren't widely deployed yet, but may see deployment= if e.g. measurement based admission control is extended to real time servi= ces. So ECN and Conex treatment should become part of the draft. Regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of L= ucy yong Sent: Tuesday, February 12, 2013 6:52 PM To: Eggert, Lars Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; tsvwg@ietf.org;= 'Carlos Pignataro (cpignata)'; nsheth@contrailsystems.com; fanyb@gsta.com;= 'Lee, Yiu'; Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-enca= p-4-ip-tunneling-00.txt Hi Lars, Thank you for the quick comments! As mentioned in the document and you point out, a block of port numbers mak= e the implementation easier, e.g. may use of mask. Regarding IANA registry = or private ports, for vendor hardware interworking, it is better to standar= dize the port number for the payload types. IANA registry is the way to ach= ieve this. This is our suggestion and we would like to hear the opinions on= this. Since we have discussed this a lot among contributors, I include them in th= is thread in case that they are not a subscriber in this WG. Regards, Lucy > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: Tuesday, February 12, 2013 10:47 AM > To: Lucy yong > Cc: tsvwg@ietf.org; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt > > Hi, > > On Feb 12, 2013, at 8:23, Lucy yong wrote: > >> Filename: draft-yong-tsvwg-udp-encap-4-ip-tunneling > > why do you require IANA to register a block of port numbers? You could > simply use a block of private ports (> 49152) without registration. A > lot of other tunneling state will need to be configured; requiring to > configure which port block is used is just one more piece of > information. > > Lars From lucy.yong@huawei.com Wed Feb 13 06:30:16 2013 Return-Path: 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 5A93521F8771 for ; Wed, 13 Feb 2013 06:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.775 X-Spam-Level: X-Spam-Status: No, score=-6.775 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAXadZSYes+o for ; Wed, 13 Feb 2013 06:30:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C6DA921F8759 for ; Wed, 13 Feb 2013 06:30:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOK70042; Wed, 13 Feb 2013 14:30:11 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 14:29:44 +0000 Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 14:29:58 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.007; Wed, 13 Feb 2013 06:29:50 -0800 From: Lucy yong To: "Ruediger.Geib@telekom.de" Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: AQHOCbwhbQn7gJHZ7kqGmdk8+Gqvxph31i+w Date: Wed, 13 Feb 2013 14:29:49 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44890583@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , "jdrake@juniper.net" , "edc@google.com" , "tsvwg@ietf.org" , "cpignata@cisco.com" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "Yiu_Lee@Cable.Comcast.com" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:30:16 -0000 Hey Ruediger, Yes, an operator needs to configure an IP tunneling application at the desi= red tunnel end points. I assume what you mean: the underlying IP network congestion and ECN notifi= cation. IMO: the tunnel egress should be able to pass the ECN status from t= he underlying network to an IP tunneling application. We will mention that = in the next version. However, the underlying network congestion control is = out of the scope. The congestion control mechanism in underlying network sh= ould be the same regardless if the udp encapsulation described in this docu= ment is used or not. Does this make a sense to you? Thank you for the comment. Lucy =20 > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Wednesday, February 13, 2013 1:31 AM > To: Lucy yong > Cc: vishwas.manral@hp.com; jdrake@juniper.net; edc@google.com; > tsvwg@ietf.org; cpignata@cisco.com; nsheth@contrailsystems.com; > fanyb@gsta.com; Yiu_Lee@Cable.Comcast.com; Xuxiaohu > Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 > Hi Lucy, >=20 > as the draft only specifies tunnel ingress and egress behaviour, these > nodes are identified and configured by an operator I guess. >=20 > Further, the draft mentions DiffServ, but it doesn't mention ECN or > Conex treatment. The latter two aren't widely deployed yet, but may see > deployment if e.g. measurement based admission control is extended to > real time services. So ECN and Conex treatment should become part of > the draft. >=20 > Regards, >=20 > Ruediger >=20 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Lucy yong > Sent: Tuesday, February 12, 2013 6:52 PM > To: Eggert, Lars > Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; > tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 > Hi Lars, >=20 > Thank you for the quick comments! >=20 > As mentioned in the document and you point out, a block of port numbers > make the implementation easier, e.g. may use of mask. Regarding IANA > registry or private ports, for vendor hardware interworking, it is > better to standardize the port number for the payload types. IANA > registry is the way to achieve this. This is our suggestion and we > would like to hear the opinions on this. >=20 > Since we have discussed this a lot among contributors, I include them > in this thread in case that they are not a subscriber in this WG. >=20 > Regards, > Lucy >=20 > > -----Original Message----- > > From: Eggert, Lars [mailto:lars@netapp.com] > > Sent: Tuesday, February 12, 2013 10:47 AM > > To: Lucy yong > > Cc: tsvwg@ietf.org; Xuxiaohu > > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg- > udp- > > encap-4-ip-tunneling-00.txt > > > > Hi, > > > > On Feb 12, 2013, at 8:23, Lucy yong wrote: > > >> Filename: draft-yong-tsvwg-udp-encap-4-ip-tunneling > > > > why do you require IANA to register a block of port numbers? You > could > > simply use a block of private ports (> 49152) without registration. A > > lot of other tunneling state will need to be configured; requiring to > > configure which port block is used is just one more piece of > > information. > > > > Lars From adrian@olddog.co.uk Wed Feb 13 08:12:33 2013 Return-Path: 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 D654921F87C3 for ; Wed, 13 Feb 2013 08:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA-uS0vz-Xr2 for ; Wed, 13 Feb 2013 08:12:33 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id D7BC921F85DF for ; Wed, 13 Feb 2013 08:12:29 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1DGBunn009861; Wed, 13 Feb 2013 16:11:57 GMT Received: from 950129200 (089144192142.atnat0001.highway.a1.net [89.144.192.142]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1DGBoKu009817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 16:11:55 GMT From: "Adrian Farrel" To: , References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> In-Reply-To: Date: Wed, 13 Feb 2013 16:11:48 -0000 Message-ID: <04f801ce0a04$d7d6f960$8784ec20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHLVK05VAwXbfafcwJxz95fvM9mpANbH2kBAwWKOZsCcb045pg2xAzg Content-Language: en-gb Cc: vishwas.manral@hp.com, jdrake@juniper.net, edc@google.com, tsvwg@ietf.org, cpignata@cisco.com, nsheth@contrailsystems.com, fanyb@gsta.com, Yiu_Lee@Cable.Comcast.com, xuxiaohu@huawei.com Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:12:34 -0000 Yes, Ruediger! I've been wittering on to the other co-authors about the need to look at congestion properly, but sadly I am no expert in that field. I'm not sure whether this is "only" mapping congestion information from the tunneled protocol into the IP/UDP of the tunnel, or whether the tunnel itself has to be congestion aware. In the former case, the requirement will be mixed (some network layers do not have congestion signaling, and some do). In the latter case, I have no clue where to start! Cheers, Adrian > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Ruediger.Geib@telekom.de > Sent: 13 February 2013 07:31 > To: lucy.yong@huawei.com > Cc: vishwas.manral@hp.com; jdrake@juniper.net; edc@google.com; > tsvwg@ietf.org; cpignata@cisco.com; nsheth@contrailsystems.com; > fanyb@gsta.com; Yiu_Lee@Cable.Comcast.com; xuxiaohu@huawei.com > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4- > ip-tunneling-00.txt > > Hi Lucy, > > as the draft only specifies tunnel ingress and egress behaviour, these nodes are > identified and configured by an operator I guess. > > Further, the draft mentions DiffServ, but it doesn't mention ECN or Conex > treatment. The latter two aren't widely deployed yet, but may see deployment if > e.g. measurement based admission control is extended to real time services. So > ECN and Conex treatment should become part of the draft. > > Regards, > > Ruediger > > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of > Lucy yong > Sent: Tuesday, February 12, 2013 6:52 PM > To: Eggert, Lars > Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; tsvwg@ietf.org; > 'Carlos Pignataro (cpignata)'; nsheth@contrailsystems.com; fanyb@gsta.com; > 'Lee, Yiu'; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4- > ip-tunneling-00.txt > > Hi Lars, > > Thank you for the quick comments! > > As mentioned in the document and you point out, a block of port numbers make > the implementation easier, e.g. may use of mask. Regarding IANA registry or > private ports, for vendor hardware interworking, it is better to standardize the > port number for the payload types. IANA registry is the way to achieve this. This > is our suggestion and we would like to hear the opinions on this. > > Since we have discussed this a lot among contributors, I include them in this > thread in case that they are not a subscriber in this WG. > > Regards, > Lucy > > > -----Original Message----- > > From: Eggert, Lars [mailto:lars@netapp.com] > > Sent: Tuesday, February 12, 2013 10:47 AM > > To: Lucy yong > > Cc: tsvwg@ietf.org; Xuxiaohu > > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > > encap-4-ip-tunneling-00.txt > > > > Hi, > > > > On Feb 12, 2013, at 8:23, Lucy yong wrote: > > >> Filename: draft-yong-tsvwg-udp-encap-4-ip-tunneling > > > > why do you require IANA to register a block of port numbers? You could > > simply use a block of private ports (> 49152) without registration. A > > lot of other tunneling state will need to be configured; requiring to > > configure which port block is used is just one more piece of > > information. > > > > Lars From touch@isi.edu Wed Feb 13 12:48:52 2013 Return-Path: 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 49DB621E8086 for ; Wed, 13 Feb 2013 12:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtNS1VNH6rMQ for ; Wed, 13 Feb 2013 12:48:51 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id BE81221E803D for ; Wed, 13 Feb 2013 12:48:51 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1DKmHrD018542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 12:48:18 -0800 (PST) Message-ID: <511BFC0C.2080003@isi.edu> Date: Wed, 13 Feb 2013 12:48:12 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lucy yong References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "vishwas.manral@hp.com" , 'John E Drake' , 'Edward Crabbe' , "tsvwg@ietf.org" , "'Carlos Pignataro \(cpignata\)'" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 20:48:52 -0000 On 2/12/2013 9:51 AM, Lucy yong wrote: > Hi Lars, > > Thank you for the quick comments! > > As mentioned in the document and you point out, a block of port numbers make the implementation easier, e.g. may use of mask. FWIW, a block of port numbers will be *very* difficult to get, and IANA doesn't reserve blocks for future use anymore. Even the current draft assumes a fairly large number - 7. If you can make this fly with 1 sure, and 2 *maybe*. But more than that is likely to have significant pushback. Keep in mind that each tunnel might support only one encapsulation, but that this can (IMO should) be determined on a per-tunnel basis either by configuration or in-band negotiation. You don't need port numbers to indicate protocol parameters. FWIW, making the implementation easier is not a consideration; reducing the number of port numbers needed is. Joe From adrian@olddog.co.uk Wed Feb 13 13:19:49 2013 Return-Path: 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 BFC7E21E8084 for ; Wed, 13 Feb 2013 13:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uqEIYPRuAlK for ; Wed, 13 Feb 2013 13:19:49 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id DC28721E8051 for ; Wed, 13 Feb 2013 13:19:48 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1DLJKkU004512; Wed, 13 Feb 2013 21:19:20 GMT Received: from 950129200 (089144192084.atnat0001.highway.a1.net [89.144.192.84]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r1DLJH95004496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Feb 2013 21:19:19 GMT From: "Adrian Farrel" To: "'Joe Touch'" , "'Lucy yong'" Date: Wed, 13 Feb 2013 21:19:15 -0000 Message-ID: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQ== Content-Language: en-gb Cc: vishwas.manral@hp.com, 'John E Drake' , 'Edward Crabbe' , tsvwg@ietf.org, "'Carlos Pignataro \(cpignata\)'" , nsheth@contrailsystems.com, fanyb@gsta.com, "'Lee, Yiu'" , 'Xuxiaohu' Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:19:49 -0000 Hi Joe, Useful to get input from one of the Expert Reviewers for user Ports. > Even the current draft assumes a fairly large number - 7. > > If you can make this fly with 1 sure, and 2 *maybe*. But more than that > is likely to have significant pushback. > > Keep in mind that each tunnel might support only one encapsulation, but > that this can (IMO should) be determined on a per-tunnel basis either by > configuration or in-band negotiation. You don't need port numbers to > indicate protocol parameters. > > FWIW, making the implementation easier is not a consideration; reducing > the number of port numbers needed is. I'm not trying to be pugilistic here, but just understand the rules and guidelines. RFC 6335 seems fairly clear to me, but it sounds like you are suggesting that user ports are an even more scarce resource such that encapsulation in UDP should either: - use a further shim to identify the payload protocol or - use a signaling protocol to arrive at an understanding of what payload protocol is being used between a pair of dynamic ports Both of these are achievable. But I wonder how that relates to the way other protocols are carried over UDP. There is, for example, an I-D just going through about encapsulating SCTP in UDP using port 9899. Now I'll grant that 9899 was assigned a million years ago, but why was a separate port assigned when there could have been signaling followed by use of a dynamic port? And so on, and so on. Each new protocol that wants to be carried in UDP asks for (and seemingly gets) a new port for the protocol to listen on. This is done without use of either of the techniques I suggested above. So what is the guidance? How does a protocol designer know whether to ask for a new port? Thanks, Adrian From touch@isi.edu Wed Feb 13 14:49:08 2013 Return-Path: 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 995B921E8099 for ; Wed, 13 Feb 2013 14:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDGUZOiq-QFK for ; Wed, 13 Feb 2013 14:49:08 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0170421E8045 for ; Wed, 13 Feb 2013 14:49:07 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1DMmKLS024615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 14:48:20 -0800 (PST) Message-ID: <511C182E.7060606@isi.edu> Date: Wed, 13 Feb 2013 14:48:14 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> In-Reply-To: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: vishwas.manral@hp.com, 'John E Drake' , 'Edward Crabbe' , tsvwg@ietf.org, "'Carlos Pignataro \(cpignata\)'" , nsheth@contrailsystems.com, fanyb@gsta.com, "'Lee, Yiu'" , 'Xuxiaohu' Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:49:08 -0000 Hi, Adrian, On 2/13/2013 1:19 PM, Adrian Farrel wrote: > Hi Joe, > > Useful to get input from one of the Expert Reviewers for user Ports. > >> Even the current draft assumes a fairly large number - 7. >> >> If you can make this fly with 1 sure, and 2 *maybe*. But more than that >> is likely to have significant pushback. >> >> Keep in mind that each tunnel might support only one encapsulation, but >> that this can (IMO should) be determined on a per-tunnel basis either by >> configuration or in-band negotiation. You don't need port numbers to >> indicate protocol parameters. >> >> FWIW, making the implementation easier is not a consideration; reducing >> the number of port numbers needed is. > > I'm not trying to be pugilistic here, but just understand the rules and > guidelines. > RFC 6335 seems fairly clear to me, but it sounds like you are suggesting that > user ports are an even more scarce resource such that encapsulation in UDP > should either: > - use a further shim to identify the payload protocol > or > - use a signaling protocol to arrive at an understanding of what > payload protocol is being used between a pair of dynamic ports > > Both of these are achievable. Yes, ports are a scarce resource. > But I wonder how that relates to the way other protocols are carried over UDP. > There is, for example, an I-D just going through about encapsulating SCTP in UDP > using port 9899. Now I'll grant that 9899 was assigned a million years ago, but > why was a separate port assigned when there could have been signaling followed > by use of a dynamic port? As you note, it was assigned a long time ago. Many things assigned in the past would have a higher hurdle now. > And so on, and so on. Each new protocol that wants to > be carried in UDP asks for (and seemingly gets) a new port for the protocol to > listen on. This is done without use of either of the techniques I suggested > above. > > So what is the guidance? > How does a protocol designer know whether to ask for a new port? We're working on a doc that explains exactly that, and it's not always an easy decision. This doc is a good example of a set of encapsulations all being developed in a coordinated fashion, for which we can realistically expect better coordinated use of the port space. It's also useful to understand the purpose of an assigned port. If you need to configure both endpoints of a tunnel, then you can just as easily add a (dynamic) port number to the configuration. Finally, the guidance, IMO, is: - if you need one port, maybe - if you need more than one, look for ways to conserve ports more carefully if more ports are needed only for performance or implementation convenience, then you probably don't need them Joe From lucy.yong@huawei.com Wed Feb 13 14:52:45 2013 Return-Path: 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 436B321E8045 for ; Wed, 13 Feb 2013 14:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.766 X-Spam-Level: X-Spam-Status: No, score=-6.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cOrwfYKZzbD for ; Wed, 13 Feb 2013 14:52:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 93BB521E8099 for ; Wed, 13 Feb 2013 14:52:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOL07104; Wed, 13 Feb 2013 22:52:37 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 22:51:06 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 22:51:22 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.007; Wed, 13 Feb 2013 14:51:13 -0800 From: Lucy yong To: "adrian@olddog.co.uk" , "'Joe Touch'" Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQACxZxA Date: Wed, 13 Feb 2013 22:51:12 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> In-Reply-To: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , 'John E Drake' , 'Edward Crabbe' , "tsvwg@ietf.org" , "'Carlos Pignataro \(cpignata\)'" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:52:45 -0000 Hi Joe, Thank you for the input.=20 IMO: The underlying IP network should use the same mechanism to indicate an= tunneled network layer protocol whether the UDP encapsulation is used or n= ot. IP header has the protocol type field for this purpose, thus it is impo= rtant to carry the same semantics in the UDP encapsulation. There are tunneled applications that are on a per-tunnel basis, but it is n= ot necessary case for all. We should not set the bar for it. Regards, Lucy =20 > -----Original Message----- > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > Sent: Wednesday, February 13, 2013 3:19 PM > To: 'Joe Touch'; Lucy yong > Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; > tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 > Hi Joe, >=20 > Useful to get input from one of the Expert Reviewers for user Ports. >=20 > > Even the current draft assumes a fairly large number - 7. > > > > If you can make this fly with 1 sure, and 2 *maybe*. But more than > that > > is likely to have significant pushback. > > > > Keep in mind that each tunnel might support only one encapsulation, > but > > that this can (IMO should) be determined on a per-tunnel basis either > by > > configuration or in-band negotiation. You don't need port numbers to > > indicate protocol parameters. > > > > FWIW, making the implementation easier is not a consideration; > reducing > > the number of port numbers needed is. >=20 > I'm not trying to be pugilistic here, but just understand the rules and > guidelines. > RFC 6335 seems fairly clear to me, but it sounds like you are > suggesting that > user ports are an even more scarce resource such that encapsulation in > UDP > should either: > - use a further shim to identify the payload protocol > or > - use a signaling protocol to arrive at an understanding of what > payload protocol is being used between a pair of dynamic ports >=20 > Both of these are achievable. >=20 > But I wonder how that relates to the way other protocols are carried > over UDP. > There is, for example, an I-D just going through about encapsulating > SCTP in UDP > using port 9899. Now I'll grant that 9899 was assigned a million years > ago, but > why was a separate port assigned when there could have been signaling > followed > by use of a dynamic port? And so on, and so on. Each new protocol that > wants to > be carried in UDP asks for (and seemingly gets) a new port for the > protocol to > listen on. This is done without use of either of the techniques I > suggested > above. >=20 > So what is the guidance? > How does a protocol designer know whether to ask for a new port? >=20 > Thanks, > Adrian >=20 >=20 From lucy.yong@huawei.com Wed Feb 13 15:02:22 2013 Return-Path: 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 36E7921E8045 for ; Wed, 13 Feb 2013 15:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.757 X-Spam-Level: X-Spam-Status: No, score=-6.757 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQMHryBVpuUN for ; Wed, 13 Feb 2013 15:02:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DB32621F8778 for ; Wed, 13 Feb 2013 15:02:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APS05917; Wed, 13 Feb 2013 23:02:18 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 23:01:54 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 23:02:17 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.007; Wed, 13 Feb 2013 15:02:05 -0800 From: Lucy yong To: Joe Touch , "adrian@olddog.co.uk" Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQAT4DIAABCFvqA= Date: Wed, 13 Feb 2013 23:02:03 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448913B5@dfweml505-mbx> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <511C182E.7060606@isi.edu> In-Reply-To: <511C182E.7060606@isi.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , 'John E Drake' , 'Edward Crabbe' , "tsvwg@ietf.org" , "'Carlos Pignataro \(cpignata\)'" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:02:22 -0000 Hi Joe, >=20 > Finally, the guidance, IMO, is: >=20 > - if you need one port, maybe >=20 > - if you need more than one, look for ways to conserve > ports more carefully >=20 > if more ports are needed only for performance > or implementation convenience, then you > probably don't need them >=20 > Joe [Lucy] We should separate two concerns. 1) if we should use UDP port to ind= icate the payload, 2) if we should reserve a block of port number for 1). I= f 1) is yes, we have to reserve the set of ports regardless they are contig= uous or not. "implementation convenience" in my previous mail applies only = too.=20 IMO: 1) for this application is necessary because we need to keep the same = semantics whether UDP encapsulation is used or not.=20 Lucy=20 From touch@isi.edu Wed Feb 13 15:08:21 2013 Return-Path: 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 5781121E8045 for ; Wed, 13 Feb 2013 15:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQO9W8S15O5Z for ; Wed, 13 Feb 2013 15:08:20 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id A617E21F851C for ; Wed, 13 Feb 2013 15:08:20 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1DN6n60026014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 15:06:49 -0800 (PST) Message-ID: <511C1C83.8040103@isi.edu> Date: Wed, 13 Feb 2013 15:06:43 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lucy yong References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:08:21 -0000 Hi, Lucy, On 2/13/2013 2:51 PM, Lucy yong wrote: > Hi Joe, > > Thank you for the input. > > IMO: The underlying IP network should use the same mechanism to > indicate an tunneled network layer protocol whether the UDP > encapsulation is used or not. IP header has the protocol type field for > this purpose, thus it is important to carry the same semantics in the > UDP encapsulation. "a tunneled network layer protocol" over UDP would be a fine goal, in which case UDP would carry only "network layer protocols". In that case, you could put IPv4 and IPv6 in the same port, because they are already identified in their own header. However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not network layer protocols. If you intend a "generic protocol for encapsulation", then you need to indicate the contents when the body isn't sufficient. The problem is that you expect to use the port number as that indication, and IMO that is not appropriate. If the type of a tunnel is persistent, you can send the indication of tunnel body type once (at tunnel establishment), periodically, or on every packet. That type would indicate differences you can't determine in-band, e.g., IP (but not IPv4 vs IPv6, MPLS, GRE, etc. I.e., the tunnel body type is your "next protocol" identifier, not the port number. > There are tunneled applications that are on a per-tunnel basis, but > itis not necessary case for all. We should not set the bar for it. AOK, but in that case a single byte is more than sufficient to differentiate the tunnel types you are supporting. Joe > > Regards, > Lucy > >> -----Original Message----- >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >> Sent: Wednesday, February 13, 2013 3:19 PM >> To: 'Joe Touch'; Lucy yong >> Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; >> tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; >> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu >> Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- >> encap-4-ip-tunneling-00.txt >> >> Hi Joe, >> >> Useful to get input from one of the Expert Reviewers for user Ports. >> >>> Even the current draft assumes a fairly large number - 7. >>> >>> If you can make this fly with 1 sure, and 2 *maybe*. But more than >> that >>> is likely to have significant pushback. >>> >>> Keep in mind that each tunnel might support only one encapsulation, >> but >>> that this can (IMO should) be determined on a per-tunnel basis either >> by >>> configuration or in-band negotiation. You don't need port numbers to >>> indicate protocol parameters. >>> >>> FWIW, making the implementation easier is not a consideration; >> reducing >>> the number of port numbers needed is. >> >> I'm not trying to be pugilistic here, but just understand the rules and >> guidelines. >> RFC 6335 seems fairly clear to me, but it sounds like you are >> suggesting that >> user ports are an even more scarce resource such that encapsulation in >> UDP >> should either: >> - use a further shim to identify the payload protocol >> or >> - use a signaling protocol to arrive at an understanding of what >> payload protocol is being used between a pair of dynamic ports >> >> Both of these are achievable. >> >> But I wonder how that relates to the way other protocols are carried >> over UDP. >> There is, for example, an I-D just going through about encapsulating >> SCTP in UDP >> using port 9899. Now I'll grant that 9899 was assigned a million years >> ago, but >> why was a separate port assigned when there could have been signaling >> followed >> by use of a dynamic port? And so on, and so on. Each new protocol that >> wants to >> be carried in UDP asks for (and seemingly gets) a new port for the >> protocol to >> listen on. This is done without use of either of the techniques I >> suggested >> above. >> >> So what is the guidance? >> How does a protocol designer know whether to ask for a new port? >> >> Thanks, >> Adrian >> >> > From touch@isi.edu Wed Feb 13 15:12:48 2013 Return-Path: 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 9F5C621E8045 for ; Wed, 13 Feb 2013 15:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.79 X-Spam-Level: X-Spam-Status: No, score=-102.79 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN6fM5ywKFek for ; Wed, 13 Feb 2013 15:12:47 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5A08B21F863A for ; Wed, 13 Feb 2013 15:12:44 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1DNAWJK026810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 15:10:32 -0800 (PST) Message-ID: <511C1D62.9040606@isi.edu> Date: Wed, 13 Feb 2013 15:10:26 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lucy yong References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <511C182E.7060606@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913B5@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D448913B5@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:12:49 -0000 Hi, Lucy, On 2/13/2013 3:02 PM, Lucy yong wrote: > Hi Joe, > >> >> Finally, the guidance, IMO, is: >> >> - if you need one port, maybe >> >> - if you need more than one, look for ways to conserve >> ports more carefully >> >> if more ports are needed only for performance >> or implementation convenience, then you >> probably don't need them >> >> Joe > > [Lucy] We should separate two concerns. 1) if we should use UDP port > to indicate the payload, 2) if we should reserve a block of port number > for 1). If 1) is yes, we have to reserve the set of ports regardless > they are contiguous or not. "implementation convenience" in my previous > mail applies only too. IMO, the reasoning is in the opposite order: 1. if you need more than one port, it's not a good solution 2. (there is no #2). > IMO: 1) for this application is necessary because we need to keep > thesame semantics whether UDP encapsulation is used or not. The semantics are not affected by whether the port number or the first byte of the UDP payload indicate the protocol type. Either way, your payload is not affected at all. Joe From lucy.yong@huawei.com Wed Feb 13 15:31:12 2013 Return-Path: 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 9175021E80A3 for ; Wed, 13 Feb 2013 15:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.749 X-Spam-Level: X-Spam-Status: No, score=-6.749 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPhpk8Ca9KjJ for ; Wed, 13 Feb 2013 15:31:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31CA421E80A1 for ; Wed, 13 Feb 2013 15:31:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APS07007; Wed, 13 Feb 2013 23:31:10 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 23:29:38 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 23:29:53 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Wed, 13 Feb 2013 15:29:44 -0800 From: Lucy yong To: Joe Touch Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQAT4DIAABCFvqD//4IFAIAAhO7Q Date: Wed, 13 Feb 2013 23:29:43 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448913D5@dfweml505-mbx> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <511C182E.7060606@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913B5@dfweml505-mbx> <511C1D62.9040606@isi.edu> In-Reply-To: <511C1D62.9040606@isi.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:31:12 -0000 > > > > [Lucy] We should separate two concerns. 1) if we should use UDP port > > to indicate the payload, 2) if we should reserve a block of port > number > > for 1). If 1) is yes, we have to reserve the set of ports regardless > > they are contiguous or not. "implementation convenience" in my > previous > > mail applies only too. >=20 > IMO, the reasoning is in the opposite order: >=20 > 1. if you need more than one port, it's not a good solution >=20 > 2. (there is no #2). >=20 > > IMO: 1) for this application is necessary because we need to keep > > thesame semantics whether UDP encapsulation is used or not. >=20 > The semantics are not affected by whether the port number or the first > byte of the UDP payload indicate the protocol type. Either way, your > payload is not affected at all. >=20 > Joe [Lucy] Thank you for the suggestion. But this means that we use different a= pproach for the IP tunneling application. If UDP encap. is not used, the pr= otocol field in IP header is used to indicate the payload type. If IDP enca= p. is used, the first nibble in the payload is used to indicate payload typ= e.=20 IPv4, IPv6, ICMP, MPLS, etc are used the first nibble. For future network v= irtualization overlay such as VXLAN and NVGRE, not sure the first byte is a= good way and the space is enough.=20 If this is the basic role, I don't know why RFC6380 is just passed. It uses= the port to indicate the payload type.=20 Regards, Lucy From lucy.yong@huawei.com Wed Feb 13 15:34:37 2013 Return-Path: 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 4BC0D21F859A for ; Wed, 13 Feb 2013 15:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.742 X-Spam-Level: X-Spam-Status: No, score=-6.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+ULx0cWmud2 for ; Wed, 13 Feb 2013 15:34:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 180CD21F855C for ; Wed, 13 Feb 2013 15:34:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APS07113; Wed, 13 Feb 2013 23:34:35 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 23:32:28 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 13 Feb 2013 23:32:43 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.007; Wed, 13 Feb 2013 15:32:32 -0800 From: Lucy yong To: Joe Touch Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQACxZxAABG/14AAEIvvQA== Date: Wed, 13 Feb 2013 23:32:32 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> In-Reply-To: <511C1C83.8040103@isi.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.94.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:34:37 -0000 >=20 > However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not network > layer > protocols. [Lucy] In your opinion, what are they?=20 Lucy >=20 > If you intend a "generic protocol for encapsulation", then you need to > indicate the contents when the body isn't sufficient. The problem is > that you expect to use the port number as that indication, and IMO that > is not appropriate. >=20 > If the type of a tunnel is persistent, you can send the indication of > tunnel body type once (at tunnel establishment), periodically, or on > every packet. That type would indicate differences you can't determine > in-band, e.g., IP (but not IPv4 vs IPv6, MPLS, GRE, etc. >=20 > I.e., the tunnel body type is your "next protocol" identifier, not the > port number. >=20 > > There are tunneled applications that are on a per-tunnel basis, but > > itis not necessary case for all. We should not set the bar for it. >=20 > AOK, but in that case a single byte is more than sufficient to > differentiate the tunnel types you are supporting. >=20 > Joe >=20 > > > > Regards, > > Lucy > > > >> -----Original Message----- > >> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >> Sent: Wednesday, February 13, 2013 3:19 PM > >> To: 'Joe Touch'; Lucy yong > >> Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; > >> tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > >> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > >> Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg- > udp- > >> encap-4-ip-tunneling-00.txt > >> > >> Hi Joe, > >> > >> Useful to get input from one of the Expert Reviewers for user Ports. > >> > >>> Even the current draft assumes a fairly large number - 7. > >>> > >>> If you can make this fly with 1 sure, and 2 *maybe*. But more than > >> that > >>> is likely to have significant pushback. > >>> > >>> Keep in mind that each tunnel might support only one encapsulation, > >> but > >>> that this can (IMO should) be determined on a per-tunnel basis > either > >> by > >>> configuration or in-band negotiation. You don't need port numbers > to > >>> indicate protocol parameters. > >>> > >>> FWIW, making the implementation easier is not a consideration; > >> reducing > >>> the number of port numbers needed is. > >> > >> I'm not trying to be pugilistic here, but just understand the rules > and > >> guidelines. > >> RFC 6335 seems fairly clear to me, but it sounds like you are > >> suggesting that > >> user ports are an even more scarce resource such that encapsulation > in > >> UDP > >> should either: > >> - use a further shim to identify the payload protocol > >> or > >> - use a signaling protocol to arrive at an understanding of what > >> payload protocol is being used between a pair of dynamic ports > >> > >> Both of these are achievable. > >> > >> But I wonder how that relates to the way other protocols are carried > >> over UDP. > >> There is, for example, an I-D just going through about encapsulating > >> SCTP in UDP > >> using port 9899. Now I'll grant that 9899 was assigned a million > years > >> ago, but > >> why was a separate port assigned when there could have been > signaling > >> followed > >> by use of a dynamic port? And so on, and so on. Each new protocol > that > >> wants to > >> be carried in UDP asks for (and seemingly gets) a new port for the > >> protocol to > >> listen on. This is done without use of either of the techniques I > >> suggested > >> above. > >> > >> So what is the guidance? > >> How does a protocol designer know whether to ask for a new port? > >> > >> Thanks, > >> Adrian > >> > >> > > From touch@isi.edu Wed Feb 13 16:33:42 2013 Return-Path: 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 B369821E80AD for ; Wed, 13 Feb 2013 16:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.782 X-Spam-Level: X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Bw0R8oLhMGu for ; Wed, 13 Feb 2013 16:33:42 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 39D8921E80A4 for ; Wed, 13 Feb 2013 16:33:42 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1E0WFAT026492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 16:32:15 -0800 (PST) Message-ID: <511C3089.2000907@isi.edu> Date: Wed, 13 Feb 2013 16:32:09 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lucy yong References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <511C182E.7060606@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913B5@dfweml505-mbx> <511C1D62.9040606@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913D5@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D448913D5@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 00:33:42 -0000 On 2/13/2013 3:29 PM, Lucy yong wrote: > > >>> >>> [Lucy] We should separate two concerns. 1) if we should use UDP port >>> to indicate the payload, 2) if we should reserve a block of port >> number >>> for 1). If 1) is yes, we have to reserve the set of ports regardless >>> they are contiguous or not. "implementation convenience" in my >> previous >>> mail applies only too. >> >> IMO, the reasoning is in the opposite order: >> >> 1. if you need more than one port, it's not a good solution >> >> 2. (there is no #2). >> >>> IMO: 1) for this application is necessary because we need to keep >>> thesame semantics whether UDP encapsulation is used or not. >> >> The semantics are not affected by whether the port number or the first >> byte of the UDP payload indicate the protocol type. Either way, your >> payload is not affected at all. >> >> Joe > [Lucy] Thank you for the suggestion. But this means that we use different approach for the IP tunneling application. If UDP encap. is not used, the protocol field in IP header is used to indicate the payload type. If IDP encap. is used, the first nibble in the payload is used to indicate payload type. > IPv4, IPv6, ICMP, MPLS, etc are used the first nibble. For future network virtualization overlay such as VXLAN and NVGRE, not sure the first byte is a good way and the space is enough. > > If this is the basic role, I don't know why RFC6380 is just passed. It uses the port to indicate the payload type. Do you mean that RFC? "Suite B Profile for Internet Protocol Security (IPsec)"? If you're referring to RFC 6830 (LISP), the difference in the two ports is that they are providing different services; one is data, one is control. FTP has a similar separation of data and control ports; that's not unusual, since it prevents head-of-line blocking if the same port is used for data and control. Joe From touch@isi.edu Wed Feb 13 16:46:03 2013 Return-Path: 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 C1B3621E80A8 for ; Wed, 13 Feb 2013 16:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7sUALvFLtIv for ; Wed, 13 Feb 2013 16:46:02 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6B121E809B for ; Wed, 13 Feb 2013 16:46:02 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id r1E0iBTo000250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 13 Feb 2013 16:44:12 -0800 (PST) Message-ID: <511C3356.40208@isi.edu> Date: Wed, 13 Feb 2013 16:44:06 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lucy yong References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 00:46:03 -0000 On 2/13/2013 3:32 PM, Lucy yong wrote: >> >> However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not network >> layer >> protocols. > [Lucy] In your opinion, what are they? Network is L3. MPLS is L2.5, more like a virtual physical layer. It typically runs outside IP. GRE and VXLAN typically run over (as a payload inside) IP, so at best they are L3.5. You can't send these over the same channel natively without some indication of what is being sent, so requiring the encapsulation to have that indication in-band would be exactly the same as would be required if these were native. Joe > Lucy >> >> If you intend a "generic protocol for encapsulation", then you need to >> indicate the contents when the body isn't sufficient. The problem is >> that you expect to use the port number as that indication, and IMO that >> is not appropriate. >> >> If the type of a tunnel is persistent, you can send the indication of >> tunnel body type once (at tunnel establishment), periodically, or on >> every packet. That type would indicate differences you can't determine >> in-band, e.g., IP (but not IPv4 vs IPv6, MPLS, GRE, etc. >> >> I.e., the tunnel body type is your "next protocol" identifier, not the >> port number. >> >>> There are tunneled applications that are on a per-tunnel basis, but >>> itis not necessary case for all. We should not set the bar for it. >> >> AOK, but in that case a single byte is more than sufficient to >> differentiate the tunnel types you are supporting. >> >> Joe >> >>> >>> Regards, >>> Lucy >>> >>>> -----Original Message----- >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>> Sent: Wednesday, February 13, 2013 3:19 PM >>>> To: 'Joe Touch'; Lucy yong >>>> Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; >>>> tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; >>>> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu >>>> Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg- >> udp- >>>> encap-4-ip-tunneling-00.txt >>>> >>>> Hi Joe, >>>> >>>> Useful to get input from one of the Expert Reviewers for user Ports. >>>> >>>>> Even the current draft assumes a fairly large number - 7. >>>>> >>>>> If you can make this fly with 1 sure, and 2 *maybe*. But more than >>>> that >>>>> is likely to have significant pushback. >>>>> >>>>> Keep in mind that each tunnel might support only one encapsulation, >>>> but >>>>> that this can (IMO should) be determined on a per-tunnel basis >> either >>>> by >>>>> configuration or in-band negotiation. You don't need port numbers >> to >>>>> indicate protocol parameters. >>>>> >>>>> FWIW, making the implementation easier is not a consideration; >>>> reducing >>>>> the number of port numbers needed is. >>>> >>>> I'm not trying to be pugilistic here, but just understand the rules >> and >>>> guidelines. >>>> RFC 6335 seems fairly clear to me, but it sounds like you are >>>> suggesting that >>>> user ports are an even more scarce resource such that encapsulation >> in >>>> UDP >>>> should either: >>>> - use a further shim to identify the payload protocol >>>> or >>>> - use a signaling protocol to arrive at an understanding of what >>>> payload protocol is being used between a pair of dynamic ports >>>> >>>> Both of these are achievable. >>>> >>>> But I wonder how that relates to the way other protocols are carried >>>> over UDP. >>>> There is, for example, an I-D just going through about encapsulating >>>> SCTP in UDP >>>> using port 9899. Now I'll grant that 9899 was assigned a million >> years >>>> ago, but >>>> why was a separate port assigned when there could have been >> signaling >>>> followed >>>> by use of a dynamic port? And so on, and so on. Each new protocol >> that >>>> wants to >>>> be carried in UDP asks for (and seemingly gets) a new port for the >>>> protocol to >>>> listen on. This is done without use of either of the techniques I >>>> suggested >>>> above. >>>> >>>> So what is the guidance? >>>> How does a protocol designer know whether to ask for a new port? >>>> >>>> Thanks, >>>> Adrian >>>> >>>> >>> From Ruediger.Geib@telekom.de Thu Feb 14 00:14:40 2013 Return-Path: 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 7CE8F11E80A2 for ; Thu, 14 Feb 2013 00:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Hciec2a3CCY for ; Thu, 14 Feb 2013 00:14:39 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74421F84FB for ; Thu, 14 Feb 2013 00:14:38 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 14 Feb 2013 09:14:36 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 14 Feb 2013 09:14:35 +0100 From: To: Date: Thu, 14 Feb 2013 09:14:34 +0100 Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: AQHOCbwhbQn7gJHZ7kqGmdk8+Gqvxph31i+wgAEgf3A= Message-ID: References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D44890583@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44890583@dfweml505-mbx> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: vishwas.manral@hp.com, jdrake@juniper.net, edc@google.com, tsvwg@ietf.org, cpignata@cisco.com, nsheth@contrailsystems.com, fanyb@gsta.com, Yiu_Lee@Cable.Comcast.com, xuxiaohu@huawei.com Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:14:40 -0000 Hi Lucy, the network section passed by the tunnel may in full or in parts support so= me form of ECN. The tunnel packets or the tunneled packets should then indi= cate the ECN markings at the ECN control end-points correctly. See http://w= ww.rfc-editor.org/rfc/rfc6040.txt You mention fragmentation in your draft. I couldn't find text about ECN and= fragmentation in RFC6040. But http://www.rfc-editor.org/rfc/rfc3168.txt co= ntains some. I'm not a TCP congestion control expert and can't discuss that. I'm rather = liking measurement based admission control for real time services, that's w= hy I'm interested in ECN as a potential mechanism. Regards, Ruediger -----Original Message----- From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Wednesday, February 13, 2013 3:30 PM To: Geib, R=FCdiger Cc: vishwas.manral@hp.com; jdrake@juniper.net; edc@google.com; tsvwg@ietf.o= rg; cpignata@cisco.com; nsheth@contrailsystems.com; fanyb@gsta.com; Yiu_Lee= @Cable.Comcast.com; Xuxiaohu Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-enca= p-4-ip-tunneling-00.txt Hey Ruediger, Yes, an operator needs to configure an IP tunneling application at the desi= red tunnel end points. I assume what you mean: the underlying IP network congestion and ECN notifi= cation. IMO: the tunnel egress should be able to pass the ECN status from t= he underlying network to an IP tunneling application. We will mention that = in the next version. However, the underlying network congestion control is = out of the scope. The congestion control mechanism in underlying network sh= ould be the same regardless if the udp encapsulation described in this docu= ment is used or not. Does this make a sense to you? Thank you for the comment. Lucy > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Wednesday, February 13, 2013 1:31 AM > To: Lucy yong > Cc: vishwas.manral@hp.com; jdrake@juniper.net; edc@google.com; > tsvwg@ietf.org; cpignata@cisco.com; nsheth@contrailsystems.com; > fanyb@gsta.com; Yiu_Lee@Cable.Comcast.com; Xuxiaohu > Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt > > Hi Lucy, > > as the draft only specifies tunnel ingress and egress behaviour, these > nodes are identified and configured by an operator I guess. > > Further, the draft mentions DiffServ, but it doesn't mention ECN or > Conex treatment. The latter two aren't widely deployed yet, but may see > deployment if e.g. measurement based admission control is extended to > real time services. So ECN and Conex treatment should become part of > the draft. > > Regards, > > Ruediger > > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf > Of Lucy yong > Sent: Tuesday, February 12, 2013 6:52 PM > To: Eggert, Lars > Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; > tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt > > Hi Lars, > > Thank you for the quick comments! > > As mentioned in the document and you point out, a block of port numbers > make the implementation easier, e.g. may use of mask. Regarding IANA > registry or private ports, for vendor hardware interworking, it is > better to standardize the port number for the payload types. IANA > registry is the way to achieve this. This is our suggestion and we > would like to hear the opinions on this. > > Since we have discussed this a lot among contributors, I include them > in this thread in case that they are not a subscriber in this WG. > > Regards, > Lucy > > > -----Original Message----- > > From: Eggert, Lars [mailto:lars@netapp.com] > > Sent: Tuesday, February 12, 2013 10:47 AM > > To: Lucy yong > > Cc: tsvwg@ietf.org; Xuxiaohu > > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg- > udp- > > encap-4-ip-tunneling-00.txt > > > > Hi, > > > > On Feb 12, 2013, at 8:23, Lucy yong wrote: > > >> Filename: draft-yong-tsvwg-udp-encap-4-ip-tunneling > > > > why do you require IANA to register a block of port numbers? You > could > > simply use a block of private ports (> 49152) without registration. A > > lot of other tunneling state will need to be configured; requiring to > > configure which port block is used is just one more piece of > > information. > > > > Lars From lucy.yong@huawei.com Thu Feb 14 07:06:50 2013 Return-Path: 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 E2F1021F886F for ; Thu, 14 Feb 2013 07:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.735 X-Spam-Level: X-Spam-Status: No, score=-6.735 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WFJKmZyF5w6k for ; Thu, 14 Feb 2013 07:06:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5879221F87FA for ; Thu, 14 Feb 2013 07:06:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOL66685; Thu, 14 Feb 2013 15:06:41 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 15:06:23 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 15:06:41 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 14 Feb 2013 07:06:33 -0800 From: Lucy yong To: Joe Touch Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQAT4DIAABCFvqD//4IFAIAAhO7Q//+R54D//5He8A== Date: Thu, 14 Feb 2013 15:06:32 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44891509@dfweml505-mbx> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <511C182E.7060606@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913B5@dfweml505-mbx> <511C1D62.9040606@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913D5@dfweml505-mbx> <511C3089.2000907@isi.edu> In-Reply-To: <511C3089.2000907@isi.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:06:51 -0000 Yes, I mean to say RFC6830. Sorry. Lucy > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, February 13, 2013 6:32 PM > To: Lucy yong > Cc: adrian@olddog.co.uk; vishwas.manral@hp.com; 'John E Drake'; 'Edward > Crabbe'; tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 >=20 >=20 > On 2/13/2013 3:29 PM, Lucy yong wrote: > > > > > >>> > >>> [Lucy] We should separate two concerns. 1) if we should use UDP > port > >>> to indicate the payload, 2) if we should reserve a block of port > >> number > >>> for 1). If 1) is yes, we have to reserve the set of ports > regardless > >>> they are contiguous or not. "implementation convenience" in my > >> previous > >>> mail applies only too. > >> > >> IMO, the reasoning is in the opposite order: > >> > >> 1. if you need more than one port, it's not a good solution > >> > >> 2. (there is no #2). > >> > >>> IMO: 1) for this application is necessary because we need to keep > >>> thesame semantics whether UDP encapsulation is used or not. > >> > >> The semantics are not affected by whether the port number or the > first > >> byte of the UDP payload indicate the protocol type. Either way, your > >> payload is not affected at all. > >> > >> Joe > > [Lucy] Thank you for the suggestion. But this means that we use > different approach for the IP tunneling application. If UDP encap. is > not used, the protocol field in IP header is used to indicate the > payload type. If IDP encap. is used, the first nibble in the payload is > used to indicate payload type. > > IPv4, IPv6, ICMP, MPLS, etc are used the first nibble. For future > network virtualization overlay such as VXLAN and NVGRE, not sure the > first byte is a good way and the space is enough. > > > > If this is the basic role, I don't know why RFC6380 is just passed. > It uses the port to indicate the payload type. >=20 > Do you mean that RFC? "Suite B Profile for Internet Protocol Security > (IPsec)"? >=20 > If you're referring to RFC 6830 (LISP), the difference in the two ports > is that they are providing different services; one is data, one is > control. FTP has a similar separation of data and control ports; that's > not unusual, since it prevents head-of-line blocking if the same port > is > used for data and control. >=20 > Joe From lucy.yong@huawei.com Thu Feb 14 07:09:01 2013 Return-Path: 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 C7E3421F88D6 for ; Thu, 14 Feb 2013 07:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.729 X-Spam-Level: X-Spam-Status: No, score=-6.729 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNE8tfQqcKlF for ; Thu, 14 Feb 2013 07:09:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2644D21F886F for ; Thu, 14 Feb 2013 07:08:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APS68604; Thu, 14 Feb 2013 15:08:58 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 15:08:30 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 15:08:55 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 14 Feb 2013 07:08:45 -0800 From: Lucy yong To: Joe Touch Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQACxZxAABG/14AAEIvvQP//ltUA//+VAVA= Date: Thu, 14 Feb 2013 15:08:44 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> <511C3356.40208@isi.edu> In-Reply-To: <511C3356.40208@isi.edu> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:09:01 -0000 Thank you to share your view. But not sure agree to. Lucy > -----Original Message----- > From: Joe Touch [mailto:touch@isi.edu] > Sent: Wednesday, February 13, 2013 6:44 PM > To: Lucy yong > Cc: adrian@olddog.co.uk; vishwas.manral@hp.com; 'John E Drake'; 'Edward > Crabbe'; tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 >=20 >=20 > On 2/13/2013 3:32 PM, Lucy yong wrote: > >> > >> However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not network > >> layer > >> protocols. > > [Lucy] In your opinion, what are they? >=20 > Network is L3. >=20 > MPLS is L2.5, more like a virtual physical layer. It typically runs > outside IP. >=20 > GRE and VXLAN typically run over (as a payload inside) IP, so at best > they are L3.5. >=20 > You can't send these over the same channel natively without some > indication of what is being sent, so requiring the encapsulation to > have > that indication in-band would be exactly the same as would be required > if these were native. >=20 > Joe >=20 > > Lucy > >> > >> If you intend a "generic protocol for encapsulation", then you need > to > >> indicate the contents when the body isn't sufficient. The problem is > >> that you expect to use the port number as that indication, and IMO > that > >> is not appropriate. > >> > >> If the type of a tunnel is persistent, you can send the indication > of > >> tunnel body type once (at tunnel establishment), periodically, or on > >> every packet. That type would indicate differences you can't > determine > >> in-band, e.g., IP (but not IPv4 vs IPv6, MPLS, GRE, etc. > >> > >> I.e., the tunnel body type is your "next protocol" identifier, not > the > >> port number. > >> > >>> There are tunneled applications that are on a per-tunnel basis, but > >>> itis not necessary case for all. We should not set the bar for it. > >> > >> AOK, but in that case a single byte is more than sufficient to > >> differentiate the tunnel types you are supporting. > >> > >> Joe > >> > >>> > >>> Regards, > >>> Lucy > >>> > >>>> -----Original Message----- > >>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >>>> Sent: Wednesday, February 13, 2013 3:19 PM > >>>> To: 'Joe Touch'; Lucy yong > >>>> Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; > >>>> tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > >>>> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > >>>> Subject: RE: [tsvwg] New Version Notification for draft-yong- > tsvwg- > >> udp- > >>>> encap-4-ip-tunneling-00.txt > >>>> > >>>> Hi Joe, > >>>> > >>>> Useful to get input from one of the Expert Reviewers for user > Ports. > >>>> > >>>>> Even the current draft assumes a fairly large number - 7. > >>>>> > >>>>> If you can make this fly with 1 sure, and 2 *maybe*. But more > than > >>>> that > >>>>> is likely to have significant pushback. > >>>>> > >>>>> Keep in mind that each tunnel might support only one > encapsulation, > >>>> but > >>>>> that this can (IMO should) be determined on a per-tunnel basis > >> either > >>>> by > >>>>> configuration or in-band negotiation. You don't need port numbers > >> to > >>>>> indicate protocol parameters. > >>>>> > >>>>> FWIW, making the implementation easier is not a consideration; > >>>> reducing > >>>>> the number of port numbers needed is. > >>>> > >>>> I'm not trying to be pugilistic here, but just understand the > rules > >> and > >>>> guidelines. > >>>> RFC 6335 seems fairly clear to me, but it sounds like you are > >>>> suggesting that > >>>> user ports are an even more scarce resource such that > encapsulation > >> in > >>>> UDP > >>>> should either: > >>>> - use a further shim to identify the payload protocol > >>>> or > >>>> - use a signaling protocol to arrive at an understanding of what > >>>> payload protocol is being used between a pair of dynamic > ports > >>>> > >>>> Both of these are achievable. > >>>> > >>>> But I wonder how that relates to the way other protocols are > carried > >>>> over UDP. > >>>> There is, for example, an I-D just going through about > encapsulating > >>>> SCTP in UDP > >>>> using port 9899. Now I'll grant that 9899 was assigned a million > >> years > >>>> ago, but > >>>> why was a separate port assigned when there could have been > >> signaling > >>>> followed > >>>> by use of a dynamic port? And so on, and so on. Each new protocol > >> that > >>>> wants to > >>>> be carried in UDP asks for (and seemingly gets) a new port for the > >>>> protocol to > >>>> listen on. This is done without use of either of the techniques I > >>>> suggested > >>>> above. > >>>> > >>>> So what is the guidance? > >>>> How does a protocol designer know whether to ask for a new port? > >>>> > >>>> Thanks, > >>>> Adrian > >>>> > >>>> > >>> From lucy.yong@huawei.com Thu Feb 14 07:14:12 2013 Return-Path: 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 D2BD721F86FF for ; Thu, 14 Feb 2013 07:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90yOStG5yBO2 for ; Thu, 14 Feb 2013 07:14:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 73B9A21F86F6 for ; Thu, 14 Feb 2013 07:14:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APS68959; Thu, 14 Feb 2013 15:14:10 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 15:13:52 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 14 Feb 2013 23:14:09 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Thu, 14 Feb 2013 07:14:01 -0800 From: Lucy yong To: "Ruediger.Geib@telekom.de" Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: AQHOCbwhbQn7gJHZ7kqGmdk8+Gqvxph31i+wgAEgf3CAAIEcAA== Date: Thu, 14 Feb 2013 15:14:00 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44891521@dfweml505-mbx> References: <2691CE0099834E4A9C5044EEC662BB9D44890235@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D448902E7@dfweml505-mbx> <2691CE0099834E4A9C5044EEC662BB9D44890583@dfweml505-mbx> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.83.199] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , "jdrake@juniper.net" , "edc@google.com" , "tsvwg@ietf.org" , "cpignata@cisco.com" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "Yiu_Lee@Cable.Comcast.com" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 15:14:13 -0000 Hi Ruediger, Thank you to info the rfc6040. Yes, we should clarity the ECN marking propa= gation and reference rfc6040. It will be fixed in next version. Regards, Lucy > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Thursday, February 14, 2013 2:15 AM > To: Lucy yong > Cc: vishwas.manral@hp.com; jdrake@juniper.net; edc@google.com; > tsvwg@ietf.org; cpignata@cisco.com; nsheth@contrailsystems.com; > fanyb@gsta.com; Yiu_Lee@Cable.Comcast.com; Xuxiaohu > Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 > Hi Lucy, >=20 > the network section passed by the tunnel may in full or in parts > support some form of ECN. The tunnel packets or the tunneled packets > should then indicate the ECN markings at the ECN control end-points > correctly. See http://www.rfc-editor.org/rfc/rfc6040.txt >=20 > You mention fragmentation in your draft. I couldn't find text about ECN > and fragmentation in RFC6040. But http://www.rfc- > editor.org/rfc/rfc3168.txt contains some. >=20 > I'm not a TCP congestion control expert and can't discuss that. I'm > rather liking measurement based admission control for real time > services, that's why I'm interested in ECN as a potential mechanism. >=20 > Regards, >=20 > Ruediger >=20 > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, February 13, 2013 3:30 PM > To: Geib, R=FCdiger > Cc: vishwas.manral@hp.com; jdrake@juniper.net; edc@google.com; > tsvwg@ietf.org; cpignata@cisco.com; nsheth@contrailsystems.com; > fanyb@gsta.com; Yiu_Lee@Cable.Comcast.com; Xuxiaohu > Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 > Hey Ruediger, >=20 > Yes, an operator needs to configure an IP tunneling application at the > desired tunnel end points. >=20 > I assume what you mean: the underlying IP network congestion and ECN > notification. IMO: the tunnel egress should be able to pass the ECN > status from the underlying network to an IP tunneling application. We > will mention that in the next version. However, the underlying network > congestion control is out of the scope. The congestion control > mechanism in underlying network should be the same regardless if the > udp encapsulation described in this document is used or not. Does this > make a sense to you? >=20 > Thank you for the comment. >=20 > Lucy >=20 > > -----Original Message----- > > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > > Sent: Wednesday, February 13, 2013 1:31 AM > > To: Lucy yong > > Cc: vishwas.manral@hp.com; jdrake@juniper.net; edc@google.com; > > tsvwg@ietf.org; cpignata@cisco.com; nsheth@contrailsystems.com; > > fanyb@gsta.com; Yiu_Lee@Cable.Comcast.com; Xuxiaohu > > Subject: RE: [tsvwg] New Version Notification for draft-yong-tsvwg- > udp- > > encap-4-ip-tunneling-00.txt > > > > Hi Lucy, > > > > as the draft only specifies tunnel ingress and egress behaviour, > these > > nodes are identified and configured by an operator I guess. > > > > Further, the draft mentions DiffServ, but it doesn't mention ECN or > > Conex treatment. The latter two aren't widely deployed yet, but may > see > > deployment if e.g. measurement based admission control is extended to > > real time services. So ECN and Conex treatment should become part of > > the draft. > > > > Regards, > > > > Ruediger > > > > -----Original Message----- > > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On > Behalf > > Of Lucy yong > > Sent: Tuesday, February 12, 2013 6:52 PM > > To: Eggert, Lars > > Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; > > tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > > nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg- > udp- > > encap-4-ip-tunneling-00.txt > > > > Hi Lars, > > > > Thank you for the quick comments! > > > > As mentioned in the document and you point out, a block of port > numbers > > make the implementation easier, e.g. may use of mask. Regarding IANA > > registry or private ports, for vendor hardware interworking, it is > > better to standardize the port number for the payload types. IANA > > registry is the way to achieve this. This is our suggestion and we > > would like to hear the opinions on this. > > > > Since we have discussed this a lot among contributors, I include them > > in this thread in case that they are not a subscriber in this WG. > > > > Regards, > > Lucy > > > > > -----Original Message----- > > > From: Eggert, Lars [mailto:lars@netapp.com] > > > Sent: Tuesday, February 12, 2013 10:47 AM > > > To: Lucy yong > > > Cc: tsvwg@ietf.org; Xuxiaohu > > > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg- > > udp- > > > encap-4-ip-tunneling-00.txt > > > > > > Hi, > > > > > > On Feb 12, 2013, at 8:23, Lucy yong wrote: > > > >> Filename: draft-yong-tsvwg-udp-encap-4-ip-tunneling > > > > > > why do you require IANA to register a block of port numbers? You > > could > > > simply use a block of private ports (> 49152) without registration. > A > > > lot of other tunneling state will need to be configured; requiring > to > > > configure which port block is used is just one more piece of > > > information. > > > > > > Lars From touch@isi.edu Thu Feb 14 09:49:08 2013 Return-Path: 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 3E61B21F884F for ; Thu, 14 Feb 2013 09:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.767 X-Spam-Level: X-Spam-Status: No, score=-102.767 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhhFYyC1Hfvv for ; Thu, 14 Feb 2013 09:49:07 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7D02A21F871F for ; Thu, 14 Feb 2013 09:49:07 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1EHmPEs002223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 Feb 2013 09:48:28 -0800 (PST) Message-ID: <511D2367.4060105@isi.edu> Date: Thu, 14 Feb 2013 09:48:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lucy yong References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> <511C3356.40208@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 17:49:08 -0000 FWIW, one additional point on this: port numbers are intended to differentiate *services*, not payload types within a given service. This draft appears to describe a single service - that of using UDP as an encapsulation for a variety of different protocol layers. That's one service, thus one port. Any further differentiation is the responsibility of this service to support, e.g., as a "protocol layer" of this service. Joe On 2/14/2013 7:08 AM, Lucy yong wrote: > Thank you to share your view. But not sure agree to. > Lucy > >> -----Original Message----- >> From: Joe Touch [mailto:touch@isi.edu] >> Sent: Wednesday, February 13, 2013 6:44 PM >> To: Lucy yong >> Cc: adrian@olddog.co.uk; vishwas.manral@hp.com; 'John E Drake'; 'Edward >> Crabbe'; tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; >> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu >> Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- >> encap-4-ip-tunneling-00.txt >> >> >> >> On 2/13/2013 3:32 PM, Lucy yong wrote: >>>> >>>> However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not network >>>> layer >>>> protocols. >>> [Lucy] In your opinion, what are they? >> >> Network is L3. >> >> MPLS is L2.5, more like a virtual physical layer. It typically runs >> outside IP. >> >> GRE and VXLAN typically run over (as a payload inside) IP, so at best >> they are L3.5. >> >> You can't send these over the same channel natively without some >> indication of what is being sent, so requiring the encapsulation to >> have >> that indication in-band would be exactly the same as would be required >> if these were native. >> >> Joe >> >>> Lucy >>>> >>>> If you intend a "generic protocol for encapsulation", then you need >> to >>>> indicate the contents when the body isn't sufficient. The problem is >>>> that you expect to use the port number as that indication, and IMO >> that >>>> is not appropriate. >>>> >>>> If the type of a tunnel is persistent, you can send the indication >> of >>>> tunnel body type once (at tunnel establishment), periodically, or on >>>> every packet. That type would indicate differences you can't >> determine >>>> in-band, e.g., IP (but not IPv4 vs IPv6, MPLS, GRE, etc. >>>> >>>> I.e., the tunnel body type is your "next protocol" identifier, not >> the >>>> port number. >>>> >>>>> There are tunneled applications that are on a per-tunnel basis, but >>>>> itis not necessary case for all. We should not set the bar for it. >>>> >>>> AOK, but in that case a single byte is more than sufficient to >>>> differentiate the tunnel types you are supporting. >>>> >>>> Joe >>>> >>>>> >>>>> Regards, >>>>> Lucy >>>>> >>>>>> -----Original Message----- >>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>> Sent: Wednesday, February 13, 2013 3:19 PM >>>>>> To: 'Joe Touch'; Lucy yong >>>>>> Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; >>>>>> tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; >>>>>> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu >>>>>> Subject: RE: [tsvwg] New Version Notification for draft-yong- >> tsvwg- >>>> udp- >>>>>> encap-4-ip-tunneling-00.txt >>>>>> >>>>>> Hi Joe, >>>>>> >>>>>> Useful to get input from one of the Expert Reviewers for user >> Ports. >>>>>> >>>>>>> Even the current draft assumes a fairly large number - 7. >>>>>>> >>>>>>> If you can make this fly with 1 sure, and 2 *maybe*. But more >> than >>>>>> that >>>>>>> is likely to have significant pushback. >>>>>>> >>>>>>> Keep in mind that each tunnel might support only one >> encapsulation, >>>>>> but >>>>>>> that this can (IMO should) be determined on a per-tunnel basis >>>> either >>>>>> by >>>>>>> configuration or in-band negotiation. You don't need port numbers >>>> to >>>>>>> indicate protocol parameters. >>>>>>> >>>>>>> FWIW, making the implementation easier is not a consideration; >>>>>> reducing >>>>>>> the number of port numbers needed is. >>>>>> >>>>>> I'm not trying to be pugilistic here, but just understand the >> rules >>>> and >>>>>> guidelines. >>>>>> RFC 6335 seems fairly clear to me, but it sounds like you are >>>>>> suggesting that >>>>>> user ports are an even more scarce resource such that >> encapsulation >>>> in >>>>>> UDP >>>>>> should either: >>>>>> - use a further shim to identify the payload protocol >>>>>> or >>>>>> - use a signaling protocol to arrive at an understanding of what >>>>>> payload protocol is being used between a pair of dynamic >> ports >>>>>> >>>>>> Both of these are achievable. >>>>>> >>>>>> But I wonder how that relates to the way other protocols are >> carried >>>>>> over UDP. >>>>>> There is, for example, an I-D just going through about >> encapsulating >>>>>> SCTP in UDP >>>>>> using port 9899. Now I'll grant that 9899 was assigned a million >>>> years >>>>>> ago, but >>>>>> why was a separate port assigned when there could have been >>>> signaling >>>>>> followed >>>>>> by use of a dynamic port? And so on, and so on. Each new protocol >>>> that >>>>>> wants to >>>>>> be carried in UDP asks for (and seemingly gets) a new port for the >>>>>> protocol to >>>>>> listen on. This is done without use of either of the techniques I >>>>>> suggested >>>>>> above. >>>>>> >>>>>> So what is the guidance? >>>>>> How does a protocol designer know whether to ask for a new port? >>>>>> >>>>>> Thanks, >>>>>> Adrian >>>>>> >>>>>> >>>>> From mthornbu@adobe.com Thu Feb 14 15:06:36 2013 Return-Path: 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 4E28D21F8802 for ; Thu, 14 Feb 2013 15:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.996 X-Spam-Level: X-Spam-Status: No, score=-105.996 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MsiNPhbr3cU for ; Thu, 14 Feb 2013 15:06:35 -0800 (PST) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF3A21F8777 for ; Thu, 14 Feb 2013 15:06:35 -0800 (PST) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUR1t+mBWGm1Syv0VSdNYjOVziXk1IKLN@postini.com; Thu, 14 Feb 2013 15:06:35 PST Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1EN6XC9029658 for ; Thu, 14 Feb 2013 15:06:33 -0800 (PST) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r1EN0aB2007398 for ; Thu, 14 Feb 2013 15:06:32 -0800 (PST) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Thu, 14 Feb 2013 15:04:38 -0800 From: Michael Thornburgh To: "tsvwg@ietf.org" Date: Thu, 14 Feb 2013 15:04:37 -0800 Thread-Topic: [tsvwg] feedback request: draft-thornburgh-adobe-rtmfp Thread-Index: Ac39s2vnDiiS8429RMSUZn9wy7XbEwNU2fdg Message-ID: <02485FF93524F8408ECA9608E47D9F20092C12DC48@nambx05.corp.adobe.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [tsvwg] feedback request: draft-thornburgh-adobe-rtmfp X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 23:06:36 -0000 there is a new revision of draft-thornburgh-adobe-rtmfp addressing detailed= feedback i received from the Responsible AD. --- Filename: draft-thornburgh-adobe-rtmfp Revision: 04 Title: Adobe's Secure Real-Time Media Flow Protocol Creation date: 2013-02-14 Group: Individual Submission Number of pages: 98 URL: http://www.ietf.org/internet-drafts/draft-thornburgh-adobe= -rtmfp-04.txt Status: http://datatracker.ietf.org/doc/draft-thornburgh-adobe-rtm= fp Htmlized: http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-thornburgh-adobe-= rtmfp-04 Abstract: This memo describes the Secure Real-Time Media Flow Protocol (RTMFP), an endpoint-to-endpoint communication protocol designed to securely transport parallel flows of real-time video, audio, and data messages, as well as bulk data, over IP networks. RTMFP has features making it effective for peer-to-peer (P2P) as well as client-server communications, even when Network Address Translators (NATs) are used. --- -michael thornburgh > From: Michael Thornburgh > Sent: Monday, January 28, 2013 3:59 PM >=20 > hello TSV Working Group. >=20 > i have recently uploaded an Internet-Draft describing a vendor network tr= ansport protocol, "Secure > Real-Time Media Flow Protocol (RTMFP)" from Adobe Systems Incorporated. = this protocol is the > foundation for the real-time and peer-to-peer communication capabilities = in Flash Player and related > Adobe products, which are widely deployed on the Internet today. we beli= eve this transport protocol > has applicability beyond Flash and will be of interest to the Internet co= mmunity. this is the > protocol presented by Matthew Kaufman to the TSV Area at IETF-77. >=20 > we are looking toward this specification being published as an Informatio= nal RFC. to that end i am > soliciting feedback, comments, and reviews of the I-D to gauge community = interest and to help us > improve its quality. >=20 > there is IPR associated with this specification, which i have disclosed a= long with a royalty-free > license declaration. that disclosure/declaration is linked from the HTML= -ized I-D page. >=20 [...] >=20 > thank you. >=20 > -michael thornburgh From gorry@erg.abdn.ac.uk Fri Feb 15 09:39:39 2013 Return-Path: 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 BE78821F86B1 for ; Fri, 15 Feb 2013 09:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bloV2awDktj2 for ; Fri, 15 Feb 2013 09:39:39 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B0D0421F8691 for ; Fri, 15 Feb 2013 09:39:38 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id D8BE12B44BB; Fri, 15 Feb 2013 17:39:37 +0000 (GMT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 2472A2B42FD; Fri, 15 Feb 2013 17:39:36 +0000 (GMT) Message-ID: <511E72D8.6040006@erg.abdn.ac.uk> Date: Fri, 15 Feb 2013 17:39:36 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: tsvwg chair , tsvwg WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [tsvwg] WG Status Update 15th Feb 2012 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 17:39:39 -0000 The list below shows the status of the working group documents as we see it. Please check below and comment on drafts using the list. Please do send any corrections/omissions to the chairs. In the last period, we confirmed adoption of the following drafts (see http://tools.ietf.org/wg/tsvwg/charters), authors please ensure an up to date copy is in the I-D repository: draft-ietf-tsvwg-sctp-failover [Milestone: Jul 2013] Adopted by WG. [Milestone: Jul 2013] draft-ietf-tsvwg-sctp-dtls-encaps [Milestone: Jan 2014] draft-ietf-tsvwg-sctp-sack-immediately [Milestone: May 2013] draft-polk-tsvwg-rsvp-app-id-vv-profiles [No milestone agreed] Please also note: 2013-02-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission Tool. 2013-02-25 (Monday): Internet Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission Tool. Best wishes, Gorry, David & James (TSVWG Chairs) Jan 2013 --- Recently published: draft-ietf-tsvwg-rsvp-security-groupkeying was published as RFC 6411. draft-ietf-tsvwg-sctpsocket was published as RFC 6458. draft-ietf-tsvwg-sctp-strrst was published as RFC 6535. draft-ietf-tsvwg-source-quench was published as RFC 6633. ------------------------------------------------------------------- IDs in RFC Editor Queue: http://www.rfc-editor.org/queue.html None. ------------------------------------------------------------------- IDs in IESG processing: draft-ietf-tsvwg-sctp-udp-encap (Replaced: draft-tuexen-sctp-udp-encap) STATUS: IESG Review, IANA comments. --- draft-ietf-tsvwg-byte-pkt-congest STATUS: Submitted to AD. ------------------------------------------------------------------- WG Drafts with Chairs: None. ------------------------------------------------------------------- WG Drafts: draft-ietf-tsvwg-rsvp-pcn Previous version : draft-karagiannis-pcn-tsvwg-rsvp-pcn WG interest in this topic recorded at IETF-81. Individual -01, 2011-07-11 AD decision allowed this to be added to the milestones The document was adopted, status will be EXP (IETF-84 due to dependencies on PCN RFCs) WG -00 8 Oct 2011 RSVP-DIR review requested 13th Oct 2012 DUE: Please comment on RVSP & PCN aspects - MILESTONE EXPIRED. --- draft-ietf-tsvwg-natsupp-tsvwg (Replaced: draft-stewart-natsupp-tsvwg) http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-natsupp/ Dependency from BEHAVE WG. Adopted as a work item 21 Sept 2010 (Gorry). WG -00, 29/11/2010 Uploaded as: draft-ietf-natsupp-tsvwg WG -01, June 1, 2011 Authors restructured draft (-03) - Done for single home - Concept done for multihome, no spec yet defined in ID. DUE: Please comment on list - MILESTONE EXPIRED. --- draft-ietf-tsvwg-sctp-failover replaces: draft-nishida-tsvwg-sctp-failover Individual-00 Presented in Prague, IETF-80. - understood not to conflict with draft-tuexen-tsvwg-sctp-multipath - PF has been coded into FreeBSD WG adoption was approved - request to comment to list on 26/6/2012. Adopted by WG. [Milestone: Jul 2013] DUE: Please comment on list. --- draft-ietf-tsvwg-sctp-dtls-encaps Formerly was draft-tuexen-tsvwg-sctp-dtls-encaps-01 Implemented in Firefox, Chrome interested. RTCweb requires this. WG adoption call after IETF-85. Adoption started 13/12/2013. Support {AB, IR, SL, MB, TD} Implemented in Firefox (FF21) Adopted as a work item. [Milestone: Jan 2014] --- draft-ietf-tsvwg-sctp-sack-immediately Formerly was draft-tuexen-tsvwg-sctp-sack-immediately -05, 2011-01-02 - Aug 2011, discussed on list and issues raised. - Implemented in BSD & Linux- 2 reviews received.DUE: Chairs need to confirm adoption (need to do work). WG adoption call after IETF-85. Adoption started 13/12/2013. Support {AB, IR, SL, MB, TD} Implemented/released in FreeBSD, partially implemented in Linux Adopted as a work item. [Milestone: May 2013] --- draft-ietf-tsvwg-intserv-multiple-tspec WG interest in this topic recorded at IETF-78. Charter update would be needed to progress this work. 5 Reviews needed to determine energy/technical direction. WG -05 (presented in Beijing, IETF-79) WG -06 (presented in Prague, IETF-80) RSVP directorate was consulted. 2 reviews from RSVP-DIR received (Bruce Davie, ?) 2 additional reviews promised (Ken Carlberg, Francois LeF) Chairs asked AD for a Charter update (IESG agreed) Draft discussed at IETF-80, and request to update charter agreed - AD advised 4 named reviewers will be required Adopted for progression as PS, for May 2012 - New approach presented following WG comments, revised MILESTONE needed. DUE: Discussion needed on list. --- draft-ietf-tsvwg-port-use-00 (replaces draft-touch-tsvwg-port-use-00) - Intended to be advice to protocol designers needing a port. 5 people have looked at this document, Prague IETF-80 Individual -01 July 2011 IETF-81 insufficient feedback from WG at this time. WG needs to assess if the new draft should be a work item. IETF-82, discussed - Chairs will ask WG to consider. Adopted by WG DUE: Revised ID expected to complete missing sections & include feedback from IETF-85 --- draft-polk-tsvwg-rsvp-app-id-vv-profiles -01 Presented in Beijing, IETF-79. -02, 14-Mar-2011 Presented IET-80. WG needs to assess if the new draft should be a work item. Seek to coordinate with music with partner ID: draft-polk-mmusic-traffic-class-for-sdp Author requests to make a WG work item... Gorry liaised with MMUSIC WG Chairs on companion draft, intended for LC early 2013. Adopted as a TSVWG work item - December 2012. DUE: Waiting for author to respond with milestone date. ------------------------------------------------------------------ Other news: RSVP Directorate (formed in May 2010) Charter updated Aug 2011. New co-chair: Rolf Winter ITU-T Study Group 12 Liaison on QoS Classes & markings for interconnection ------------------------------------------------------------------ From gorry@erg.abdn.ac.uk Fri Feb 15 10:13:00 2013 Return-Path: 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 05DCF21F884B for ; Fri, 15 Feb 2013 10:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JlcYb1NYlbDw for ; Fri, 15 Feb 2013 10:12:59 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id EA04521F8848 for ; Fri, 15 Feb 2013 10:12:58 -0800 (PST) Received: by spey.erg.abdn.ac.uk (Postfix, from userid 5001) id 341EB2B44CE; Fri, 15 Feb 2013 18:12:58 +0000 (GMT) Received: from gorry-mac.erg.abdn.ac.uk (gorry-mac.erg.abdn.ac.uk [139.133.207.5]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 19C872B42FD; Fri, 15 Feb 2013 18:12:49 +0000 (GMT) Message-ID: <511E7AA1.6090905@erg.abdn.ac.uk> Date: Fri, 15 Feb 2013 18:12:49 +0000 From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Joe Touch References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> <511C3356.40208@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> <511D2367.4060105@isi.edu> In-Reply-To: <511D2367.4060105@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 18:13:00 -0000 I've just looked at this now, and have some very quick observations, that I'll post to the list: I am surprised to see that you think RFC5405 design considerations do not apply. As I recall, the RFC explicitly speaks about tunnels (e.g. section 3.1). Section 2 describes the use of the zero UDP checksum option for IPv6, which is interesting, but I note that the draft does not consider the mechanisms that have been specified in I am not sure why the proposed protocol uses 9 port numbers, echoing Joe's comment below that they are not usually utilised to differentiate the payload. I'm assuming the src port would be different for each flow, so from the point of ECMP, wouldn't that be enough entropy to separate the traffic? Gorry (as a list member) On 14/02/2013 17:48, Joe Touch wrote: > FWIW, one additional point on this: > > port numbers are intended to differentiate *services*, not payload types > within a given service. > > This draft appears to describe a single service - that of using UDP as > an encapsulation for a variety of different protocol layers. That's one > service, thus one port. Any further differentiation is the > responsibility of this service to support, e.g., as a "protocol layer" > of this service. > > Joe > > On 2/14/2013 7:08 AM, Lucy yong wrote: >> Thank you to share your view. But not sure agree to. >> Lucy >> >>> -----Original Message----- >>> From: Joe Touch [mailto:touch@isi.edu] >>> Sent: Wednesday, February 13, 2013 6:44 PM >>> To: Lucy yong >>> Cc: adrian@olddog.co.uk; vishwas.manral@hp.com; 'John E Drake'; 'Edward >>> Crabbe'; tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; >>> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu >>> Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- >>> encap-4-ip-tunneling-00.txt >>> >>> >>> >>> On 2/13/2013 3:32 PM, Lucy yong wrote: >>>>> >>>>> However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not network >>>>> layer >>>>> protocols. >>>> [Lucy] In your opinion, what are they? >>> >>> Network is L3. >>> >>> MPLS is L2.5, more like a virtual physical layer. It typically runs >>> outside IP. >>> >>> GRE and VXLAN typically run over (as a payload inside) IP, so at best >>> they are L3.5. >>> >>> You can't send these over the same channel natively without some >>> indication of what is being sent, so requiring the encapsulation to >>> have >>> that indication in-band would be exactly the same as would be required >>> if these were native. >>> >>> Joe >>> >>>> Lucy >>>>> >>>>> If you intend a "generic protocol for encapsulation", then you need >>> to >>>>> indicate the contents when the body isn't sufficient. The problem is >>>>> that you expect to use the port number as that indication, and IMO >>> that >>>>> is not appropriate. >>>>> >>>>> If the type of a tunnel is persistent, you can send the indication >>> of >>>>> tunnel body type once (at tunnel establishment), periodically, or on >>>>> every packet. That type would indicate differences you can't >>> determine >>>>> in-band, e.g., IP (but not IPv4 vs IPv6, MPLS, GRE, etc. >>>>> >>>>> I.e., the tunnel body type is your "next protocol" identifier, not >>> the >>>>> port number. >>>>> >>>>>> There are tunneled applications that are on a per-tunnel basis, but >>>>>> itis not necessary case for all. We should not set the bar for it. >>>>> >>>>> AOK, but in that case a single byte is more than sufficient to >>>>> differentiate the tunnel types you are supporting. >>>>> >>>>> Joe >>>>> >>>>>> >>>>>> Regards, >>>>>> Lucy >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] >>>>>>> Sent: Wednesday, February 13, 2013 3:19 PM >>>>>>> To: 'Joe Touch'; Lucy yong >>>>>>> Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; >>>>>>> tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; >>>>>>> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu >>>>>>> Subject: RE: [tsvwg] New Version Notification for draft-yong- >>> tsvwg- >>>>> udp- >>>>>>> encap-4-ip-tunneling-00.txt >>>>>>> >>>>>>> Hi Joe, >>>>>>> >>>>>>> Useful to get input from one of the Expert Reviewers for user >>> Ports. >>>>>>> >>>>>>>> Even the current draft assumes a fairly large number - 7. >>>>>>>> >>>>>>>> If you can make this fly with 1 sure, and 2 *maybe*. But more >>> than >>>>>>> that >>>>>>>> is likely to have significant pushback. >>>>>>>> >>>>>>>> Keep in mind that each tunnel might support only one >>> encapsulation, >>>>>>> but >>>>>>>> that this can (IMO should) be determined on a per-tunnel basis >>>>> either >>>>>>> by >>>>>>>> configuration or in-band negotiation. You don't need port numbers >>>>> to >>>>>>>> indicate protocol parameters. >>>>>>>> >>>>>>>> FWIW, making the implementation easier is not a consideration; >>>>>>> reducing >>>>>>>> the number of port numbers needed is. >>>>>>> >>>>>>> I'm not trying to be pugilistic here, but just understand the >>> rules >>>>> and >>>>>>> guidelines. >>>>>>> RFC 6335 seems fairly clear to me, but it sounds like you are >>>>>>> suggesting that >>>>>>> user ports are an even more scarce resource such that >>> encapsulation >>>>> in >>>>>>> UDP >>>>>>> should either: >>>>>>> - use a further shim to identify the payload protocol >>>>>>> or >>>>>>> - use a signaling protocol to arrive at an understanding of what >>>>>>> payload protocol is being used between a pair of dynamic >>> ports >>>>>>> >>>>>>> Both of these are achievable. >>>>>>> >>>>>>> But I wonder how that relates to the way other protocols are >>> carried >>>>>>> over UDP. >>>>>>> There is, for example, an I-D just going through about >>> encapsulating >>>>>>> SCTP in UDP >>>>>>> using port 9899. Now I'll grant that 9899 was assigned a million >>>>> years >>>>>>> ago, but >>>>>>> why was a separate port assigned when there could have been >>>>> signaling >>>>>>> followed >>>>>>> by use of a dynamic port? And so on, and so on. Each new protocol >>>>> that >>>>>>> wants to >>>>>>> be carried in UDP asks for (and seemingly gets) a new port for the >>>>>>> protocol to >>>>>>> listen on. This is done without use of either of the techniques I >>>>>>> suggested >>>>>>> above. >>>>>>> >>>>>>> So what is the guidance? >>>>>>> How does a protocol designer know whether to ask for a new port? >>>>>>> >>>>>>> Thanks, >>>>>>> Adrian >>>>>>> >>>>>>> >>>>>> > From chelai@cisco.com Fri Feb 15 11:03:17 2013 Return-Path: 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 6415E21F8821 for ; Fri, 15 Feb 2013 11:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eojL-gb7O1Rc for ; Fri, 15 Feb 2013 11:03:16 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 90A8221F8717 for ; Fri, 15 Feb 2013 11:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3672; q=dns/txt; s=iport; t=1360954996; x=1362164596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=35i1qtPbHW1PC3cd6MyoNUdaF+SEpiBKHhwhVJN1+bs=; b=dzRw1XtdX9mTbuAoGawaKhTm5d+vOiYM8tfIcssF6u3FM4TftRdhwl+C vX5GIx9swQx9x8CYc56uXWBhsv3NPuL8mUbPxZNbqsoz0B7g8ZYOIxp9S r47zwnKOcDKupk0DsXNN0oy5lyY1X7UdxHmnEjXzFk2CSTt+PfzkTfwdX Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANOFHlGtJXHA/2dsb2JhbABEhkm5KQ1wFnOCHwEBAQQjETESAgwEAgEIEQQBAQMCBh0DAgICMBQBBwEIAQEEDgUIAYgJDKp5kjiBI41XJgsHBoInMmEDl0WPOIMHgic X-IronPort-AV: E=Sophos;i="4.84,675,1355097600"; d="scan'208";a="177664913" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 15 Feb 2013 19:03:16 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1FJ3GMA008508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 15 Feb 2013 19:03:16 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 15 Feb 2013 13:03:15 -0600 From: "Cheng-Jia Lai (chelai)" To: "tsvwg@ietf.org" Thread-Topic: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalizer-00.txt Thread-Index: Ac4GcBXrNOtmIMweTbifdbQEwQJH6QFPqcaQ Date: Fri, 15 Feb 2013 19:03:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.160.150] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Wenyi Wang \(wenywang\)" , "Stan Yang \(stanyang\)" , "Toerless Eckert \(eckert\)" , "Fred Yip \(fyip\)" Subject: Re: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalizer-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 19:03:17 -0000 SGkgZm9sa3MsDQoNCldpbGwgYXBwcmVjaWF0ZSBzb21lIGNvbW1lbnRzIG9uIHRoaXMgbmV3IGRy YWZ0IHRoYXQgd2UgcG9zdGVkIGxhc3Qgd2VlayBmb3IgTk0gaW4gQUYgUEhCIGdyb3VwcyBvZiBE aWZmU2Vydi4NCg0KVGhhbmtzLA0KQ0oNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHRzdndnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp0c3Z3Zy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQ2hlbmctSmlhIExhaSAoY2hlbGFpKQ0KU2VudDogRnJpZGF5LCBGZWJy dWFyeSAwOCwgMjAxMyA3OjAxIFBNDQpUbzogdHN2d2dAaWV0Zi5vcmcNCkNjOiBXZW55aSBXYW5n ICh3ZW55d2FuZyk7IFN0YW4gWWFuZyAoc3RhbnlhbmcpOyBUb2VybGVzcyBFY2tlcnQgKGVja2Vy dCk7IEZyZWQgWWlwIChmeWlwKQ0KU3ViamVjdDogW3RzdndnXSBGVzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1sYWktdHN2d2ctbm9ybWFsaXplci0wMC50eHQNCg0KSGkgYWxs LA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyBJbnRlcm5ldCBkcmFmdCB0byBkZXNjcmliZSBh IE5vcm1hbGl6YXRpb24gTWFya2VyIChOTSkgZm9yIERpZmZTZXJ2IEFGIFBIQiBncm91cHMsIGJh c2VkIG9uIG91ciB3b3JrIGF0IENpc2NvLiBUaGUgZ29hbCBvZiBOTSBkZXBsb3ltZW50IGlzIHRv IGNyZWF0ZSBhIG5ldyBpbmNlbnRpdmUgZm9yIHZpZGVvIGVuY29kZXJzIHRvIGdlbmVyYXRlIG1v cmUgZGlzY2FyZGFibGUgcGFja2V0cyB3aGVuIHVzaW5nIEFGIFBIQiBpbiBESWZmU2Vydi4gV2Ug YXJlIGxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIHJldmlldyBjb21tZW50cy4NCg0KQmVzdCByZWdh cmRzLA0KQ0oNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBG cmlkYXksIEZlYnJ1YXJ5IDA4LCAyMDEzIDY6MjUgUE0NClRvOiBDaGVuZy1KaWEgTGFpIChjaGVs YWkpDQpDYzogV2VueWkgV2FuZyAod2VueXdhbmcpOyBTdGFuIFlhbmcgKHN0YW55YW5nKTsgVG9l cmxlc3MgRWNrZXJ0IChlY2tlcnQpOyBGcmVkIFlpcCAoZnlpcCkNClN1YmplY3Q6IE5ldyBWZXJz aW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXItMDAudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxhaS10c3Z3Zy1ub3JtYWxpemVyLTAwLnR4 dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDaGVuZy1KaWEgTGFpIGFuZCBw b3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtbGFpLXRz dndnLW5vcm1hbGl6ZXINClJldmlzaW9uOgkgMDANClRpdGxlOgkJIE5vcm1hbGl6YXRpb24gTWFy a2VyIGZvciBBRiBQSEIgR3JvdXAgaW4gRGlmZlNlcnYNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTAy LTA4DQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTUN ClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXItMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGFpLXRzdndnLW5vcm1hbGl6ZXINCkh0bWxp emVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGFpLXRzdndnLW5v cm1hbGl6ZXItMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgbWVtbyBkZXNjcmliZXMgYSBOb3Jt YWxpemF0aW9uIE1hcmtlciAoTk0pIGF0IERpZmZTZXJ2IChEUykNCiAgIG5vZGVzIHRvIG5vcm1h bGl6ZSB0aGUgZGlzdHJpYnV0aW9uIG9mIERTIGNvZGVwb2ludCAoRFNDUCkgbWFya2luZ3MNCiAg IGZvciBhbiBBc3N1cmVkIEZvcndhcmRpbmcgKEFGKSBQZXItSG9wIEJlaGF2aW9yIChQSEIpIGdy b3VwLiAgTk0gaXMNCiAgIHVzZWZ1bCBmb3IgdHJhZmZpYyBjb25kaXRpb25pbmcgd2l0aCBBY3Rp dmUgUXVldWUgTWFuYWdlbWVudCAoQVFNKQ0KICAgd2hlbiB0aGUgQUYgUEhCIGdyb3VwIGlzIGRl cGxveWVkIGZvciBtdWx0aW1lZGlhIHNlcnZpY2UgY2xhc3NlcyB0aGF0DQogICBjYXJyeSB2aWRl byBwYWNrZXRzIHdpdGggYWR2YW5jZWQgY29kZWMgdGVjaG5vbG9naWVzLiAgVXNpbmcgTk0gY2Fu DQogICBvZmZlciBhbiBpbmNlbnRpdmUgdGhhdCBpcyBob3dldmVyIG1pc3NpbmcgaW4gdG9kYXkn cyBlY29zeXN0ZW0gb2YNCiAgIHByYWN0aWNhbCBkZXBsb3ltZW50LCBpLmUuLCB3aGVuIGNvbmdl c3Rpb24gb2NjdXJzIGluIHRoZSBBRiBQSEINCiAgIGdyb3VwLCB0aGUgbmV0d29yayBzaG91bGQg YWxsb3cgYSB2aWRlbyBjb2RlYyB0byBiZW5lZml0IGZyb20gaXRzDQogICBlZmZvcnQgb2YgZ2Vu ZXJhdGluZyBmaW5lciBsYXllcnMgb2YgaW50cmEtZmxvdyBwcmVjZWRlbmNlIChJRlApIHdpdGgN CiAgIGRpc2NhcmRhYmxlIHBhY2tldHMgaW4gYSBtb3JlIGJhbGFuY2VkIGRpc3RyaWJ1dGlvbi4N Cg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoN Cg== From lucy.yong@huawei.com Fri Feb 15 12:12:29 2013 Return-Path: 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 D5AAF21F863C for ; Fri, 15 Feb 2013 12:12:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.719 X-Spam-Level: X-Spam-Status: No, score=-6.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfmasBERo5Vz for ; Fri, 15 Feb 2013 12:12:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 55CBB21F85A0 for ; Fri, 15 Feb 2013 12:12:27 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APT62495; Fri, 15 Feb 2013 20:12:23 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 15 Feb 2013 20:12:01 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 15 Feb 2013 20:12:07 +0000 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.007; Fri, 15 Feb 2013 12:11:56 -0800 From: Lucy yong To: "gorry@erg.abdn.ac.uk" , Joe Touch Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQACxZxAABG/14AAEIvvQP//ltUA//+VAVCAAYkugIABmSiAgABsvTA= Date: Fri, 15 Feb 2013 20:11:55 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D44891B91@dfweml505-mbx> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> <511C3356.40208@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> <511D2367.4060105@isi.edu> <511E7AA1.6090905@erg.abdn.ac.uk> In-Reply-To: <511E7AA1.6090905@erg.abdn.ac.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.87.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , "'Carlos Pignataro \(cpignata\)'" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 20:12:29 -0000 Hi Gorry, Thank you to look at this and give some feedbacks. RFC5405 provides the design considerations for the case that use of UDP pr= ovides a tunnel mechanism to a upper layer application. This is not the int= ention of this draft. This draft is about the use UDP header to provide the= load balancing information and payload type for an IP network, which may a= pplies to various IP tunneling application. It has no intention to use the = UDP to provide any transport function. Therefore, it states that the design= consideration in RFC5405 does not apply to this application. Regarding the zero UDP checksum for IPv6, thank you for the point out. We w= ill fix the text to align with the draft-ietf-6man-updchecksums.=20 We thank Joe for the comments and guideline about UDP port assignment rule.= Src port have 16 bits. Do you suggest using the src port for both entropy = and payload type? This is a potential alternative. We like to get the commu= nity feedback on where is the right place to encode the payload type for th= is application. =20 The 9 addition port number makes total 16 port numbers, which is a pretty n= umber. Regards, Lucy=20 > -----Original Message----- > From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] > Sent: Friday, February 15, 2013 12:13 PM > To: Joe Touch > Cc: Lucy yong; vishwas.manral@hp.com; 'Carlos Pignataro (cpignata)'; > 'Edward Crabbe'; tsvwg@ietf.org; 'John E Drake'; > nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 > I've just looked at this now, and have some very quick observations, > that I'll post to the list: >=20 > I am surprised to see that you think RFC5405 design considerations do > not apply. As I recall, the RFC explicitly speaks about tunnels (e.g. > section 3.1). >=20 > Section 2 describes the use of the zero UDP checksum option for IPv6, > which is interesting, but I note that the draft does not consider the > mechanisms that have been specified in >=20 > I am not sure why the proposed protocol uses 9 port numbers, echoing > Joe's comment below that they are not usually utilised to differentiate > the payload. I'm assuming the src port would be different for each flow, > so from the point of ECMP, wouldn't that be enough entropy to separate > the traffic? >=20 > Gorry (as a list member) >=20 > On 14/02/2013 17:48, Joe Touch wrote: > > FWIW, one additional point on this: > > > > port numbers are intended to differentiate *services*, not payload > types > > within a given service. > > > > This draft appears to describe a single service - that of using UDP > as > > an encapsulation for a variety of different protocol layers. That's > one > > service, thus one port. Any further differentiation is the > > responsibility of this service to support, e.g., as a "protocol > layer" > > of this service. > > > > Joe > > > > On 2/14/2013 7:08 AM, Lucy yong wrote: > >> Thank you to share your view. But not sure agree to. > >> Lucy > >> > >>> -----Original Message----- > >>> From: Joe Touch [mailto:touch@isi.edu] > >>> Sent: Wednesday, February 13, 2013 6:44 PM > >>> To: Lucy yong > >>> Cc: adrian@olddog.co.uk; vishwas.manral@hp.com; 'John E Drake'; > 'Edward > >>> Crabbe'; tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > >>> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > >>> Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg- > udp- > >>> encap-4-ip-tunneling-00.txt > >>> > >>> > >>> > >>> On 2/13/2013 3:32 PM, Lucy yong wrote: > >>>>> > >>>>> However, GRE, NVGRE, MPLS down, MPLS up, and VXLAN are not > network > >>>>> layer > >>>>> protocols. > >>>> [Lucy] In your opinion, what are they? > >>> > >>> Network is L3. > >>> > >>> MPLS is L2.5, more like a virtual physical layer. It typically runs > >>> outside IP. > >>> > >>> GRE and VXLAN typically run over (as a payload inside) IP, so at > best > >>> they are L3.5. > >>> > >>> You can't send these over the same channel natively without some > >>> indication of what is being sent, so requiring the encapsulation to > >>> have > >>> that indication in-band would be exactly the same as would be > required > >>> if these were native. > >>> > >>> Joe > >>> > >>>> Lucy > >>>>> > >>>>> If you intend a "generic protocol for encapsulation", then you > need > >>> to > >>>>> indicate the contents when the body isn't sufficient. The problem > is > >>>>> that you expect to use the port number as that indication, and > IMO > >>> that > >>>>> is not appropriate. > >>>>> > >>>>> If the type of a tunnel is persistent, you can send the > indication > >>> of > >>>>> tunnel body type once (at tunnel establishment), periodically, or > on > >>>>> every packet. That type would indicate differences you can't > >>> determine > >>>>> in-band, e.g., IP (but not IPv4 vs IPv6, MPLS, GRE, etc. > >>>>> > >>>>> I.e., the tunnel body type is your "next protocol" identifier, > not > >>> the > >>>>> port number. > >>>>> > >>>>>> There are tunneled applications that are on a per-tunnel basis, > but > >>>>>> itis not necessary case for all. We should not set the bar for > it. > >>>>> > >>>>> AOK, but in that case a single byte is more than sufficient to > >>>>> differentiate the tunnel types you are supporting. > >>>>> > >>>>> Joe > >>>>> > >>>>>> > >>>>>> Regards, > >>>>>> Lucy > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Adrian Farrel [mailto:adrian@olddog.co.uk] > >>>>>>> Sent: Wednesday, February 13, 2013 3:19 PM > >>>>>>> To: 'Joe Touch'; Lucy yong > >>>>>>> Cc: vishwas.manral@hp.com; 'John E Drake'; 'Edward Crabbe'; > >>>>>>> tsvwg@ietf.org; 'Carlos Pignataro (cpignata)'; > >>>>>>> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; > Xuxiaohu > >>>>>>> Subject: RE: [tsvwg] New Version Notification for draft-yong- > >>> tsvwg- > >>>>> udp- > >>>>>>> encap-4-ip-tunneling-00.txt > >>>>>>> > >>>>>>> Hi Joe, > >>>>>>> > >>>>>>> Useful to get input from one of the Expert Reviewers for user > >>> Ports. > >>>>>>> > >>>>>>>> Even the current draft assumes a fairly large number - 7. > >>>>>>>> > >>>>>>>> If you can make this fly with 1 sure, and 2 *maybe*. But more > >>> than > >>>>>>> that > >>>>>>>> is likely to have significant pushback. > >>>>>>>> > >>>>>>>> Keep in mind that each tunnel might support only one > >>> encapsulation, > >>>>>>> but > >>>>>>>> that this can (IMO should) be determined on a per-tunnel basis > >>>>> either > >>>>>>> by > >>>>>>>> configuration or in-band negotiation. You don't need port > numbers > >>>>> to > >>>>>>>> indicate protocol parameters. > >>>>>>>> > >>>>>>>> FWIW, making the implementation easier is not a consideration; > >>>>>>> reducing > >>>>>>>> the number of port numbers needed is. > >>>>>>> > >>>>>>> I'm not trying to be pugilistic here, but just understand the > >>> rules > >>>>> and > >>>>>>> guidelines. > >>>>>>> RFC 6335 seems fairly clear to me, but it sounds like you are > >>>>>>> suggesting that > >>>>>>> user ports are an even more scarce resource such that > >>> encapsulation > >>>>> in > >>>>>>> UDP > >>>>>>> should either: > >>>>>>> - use a further shim to identify the payload protocol > >>>>>>> or > >>>>>>> - use a signaling protocol to arrive at an understanding of > what > >>>>>>> payload protocol is being used between a pair of dynamic > >>> ports > >>>>>>> > >>>>>>> Both of these are achievable. > >>>>>>> > >>>>>>> But I wonder how that relates to the way other protocols are > >>> carried > >>>>>>> over UDP. > >>>>>>> There is, for example, an I-D just going through about > >>> encapsulating > >>>>>>> SCTP in UDP > >>>>>>> using port 9899. Now I'll grant that 9899 was assigned a > million > >>>>> years > >>>>>>> ago, but > >>>>>>> why was a separate port assigned when there could have been > >>>>> signaling > >>>>>>> followed > >>>>>>> by use of a dynamic port? And so on, and so on. Each new > protocol > >>>>> that > >>>>>>> wants to > >>>>>>> be carried in UDP asks for (and seemingly gets) a new port for > the > >>>>>>> protocol to > >>>>>>> listen on. This is done without use of either of the techniques > I > >>>>>>> suggested > >>>>>>> above. > >>>>>>> > >>>>>>> So what is the guidance? > >>>>>>> How does a protocol designer know whether to ask for a new port? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Adrian > >>>>>>> > >>>>>>> > >>>>>> > > From touch@isi.edu Fri Feb 15 13:21:33 2013 Return-Path: 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 74C4A21F8622 for ; Fri, 15 Feb 2013 13:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.855 X-Spam-Level: X-Spam-Status: No, score=-102.855 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdL8+b-8catN for ; Fri, 15 Feb 2013 13:21:33 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id F222221F859D for ; Fri, 15 Feb 2013 13:21:32 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1FLKrZf019142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Feb 2013 13:20:53 -0800 (PST) Message-ID: <511EA6B4.7030509@isi.edu> Date: Fri, 15 Feb 2013 13:20:52 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lucy yong References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> <511C3356.40208@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> <511D2367.4060105@isi.edu> <511E7AA1.6090905@erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D44891B91@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D44891B91@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "gorry@erg.abdn.ac.uk" , "vishwas.manral@hp.com" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "'Carlos Pignataro \(cpignata\)'" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 21:21:33 -0000 Hi, Lucy (et al.), On 2/15/2013 12:11 PM, Lucy yong wrote: ... > We thank Joe for the comments and guideline about UDP port > assignment rule. Src port have 16 bits. Do you suggest using the src > port for both entropy and payload type? Source port helps differentiate different streams between two IP endpoints to the same service, but I would not strictly call that "entropy". It can be useful to keep flows separate, as Gorry noted, and can indicate a flow type *after* some other mechanism (in band or out of band) provides initial information of the flow type - that way you can avoid needing to send a shim layer in every payload. The source port cannot be used as payload type. Depending on your view, either you can't reserve them at all or they are reserved by the same IANA process as destination ports (I've heard both arguments, but without going into detail they're equivalent here - the source port isn't useful as a known quantity). Joe From gorry@erg.abdn.ac.uk Sat Feb 16 01:04:27 2013 Return-Path: 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 DA2D521F86AD for ; Sat, 16 Feb 2013 01:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0I1yZgkKN1E for ; Sat, 16 Feb 2013 01:04:27 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id DD1B921F86A2 for ; Sat, 16 Feb 2013 01:04:26 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id E84B32B4044; Sat, 16 Feb 2013 09:04:24 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Sat, 16 Feb 2013 09:04:25 -0000 Message-ID: <59633c251a788b87970555742a1bd7e3.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <511EA6B4.7030509@isi.edu> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> <511C3356.40208@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> <511D2367.4060105@isi.edu> <511E7AA1.6090905@erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D44891B91@dfweml505-mbx> <511EA6B4.7030509@isi.edu> Date: Sat, 16 Feb 2013 09:04:25 -0000 From: gorry@erg.abdn.ac.uk To: "Joe Touch" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: "gorry@erg.abdn.ac.uk" , "vishwas.manral@hp.com" , 'Edward Crabbe' , "tsvwg@ietf.org" , 'John E Drake' , "'Carlos Pignataro \(cpignata\)'" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 09:04:28 -0000 Hi, Some more thoughts on port usage: I would like to understand whether we REALLY need a separate destination port per protocol. I think that it would relatively easy to use a header byte in the payload to differentiate tunnel control messages and tunnelled (encapsulated) IP packets. If you do this, wouldn't it be possible to run over one port. GRE, for example, runs over one IP codepoint. When you talk about the source port reflecting payload type, were you suggesting a tunnel control protocol negotiates using a setup packet what protocol is being used? - that seems a possibility with each (src,dst) pair being dynamically transported protocol? (or have I misunderstood?) On the source port, I was expecting that each "tunnel" could have one source port. I'm not clear of your use cases, are we expecting multiple associations to the same destination that want to use with ECMP for example? in which case, this seems it would imply multiple src ports in use from the same sender, allowing each to be independently be routed? (This was why I mentioned "entropy" for ECMP). Gorry > Hi, Lucy (et al.), > > On 2/15/2013 12:11 PM, Lucy yong wrote: > ... >> We thank Joe for the comments and guideline about UDP port >> assignment rule. Src port have 16 bits. Do you suggest using the src >> port for both entropy and payload type? > > Source port helps differentiate different streams between two IP > endpoints to the same service, but I would not strictly call that > "entropy". It can be useful to keep flows separate, as Gorry noted, and > can indicate a flow type *after* some other mechanism (in band or out of > band) provides initial information of the flow type - that way you can > avoid needing to send a shim layer in every payload. > > The source port cannot be used as payload type. Depending on your view, > either you can't reserve them at all or they are reserved by the same > IANA process as destination ports (I've heard both arguments, but > without going into detail they're equivalent here - the source port > isn't useful as a known quantity). > > Joe > From internet-drafts@ietf.org Sat Feb 16 07:57:43 2013 Return-Path: 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 EF30321F843C; Sat, 16 Feb 2013 07:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrXyoUtuO-Hn; Sat, 16 Feb 2013 07:57:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961BF21F842B; Sat, 16 Feb 2013 07:57:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130216155742.7456.91242.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 07:57:42 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-dtls-encaps-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 15:57:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : DTLS Encapsulation of SCTP Packets for RTCWEB Author(s) : Randell Jesup Salvatore Loreto Randall R. Stewart Michael Tuexen Filename : draft-ietf-tsvwg-sctp-dtls-encaps-00.txt Pages : 8 Date : 2013-02-16 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol originally defined to run on top of the network protocols IPv4 or IPv6. This memo document specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol. SCTP over DTLS is used by the RTCWeb protocol suite for transporting non- media data between browsers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-dtls-encaps-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Sat Feb 16 12:56:35 2013 Return-Path: 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 1C34321F89E5; Sat, 16 Feb 2013 12:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8Xy9Ay4FSh4; Sat, 16 Feb 2013 12:56:34 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B34221F8658; Sat, 16 Feb 2013 12:56:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130216205634.11252.40703.idtracker@ietfa.amsl.com> Date: Sat, 16 Feb 2013 12:56:34 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-sack-immediately-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 20:56:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : SACK-IMMEDIATELY Extension for the Stream Control Transm= ission Protocol Author(s) : Michael Tuexen Irene Ruengeler Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-sack-immediately-00.txt Pages : 7 Date : 2013-02-16 Abstract: This document defines a method for the sender of a DATA chunk to indicate that the corresponding SACK chunk should be sent back immediately and not be delayed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-sack-immediately There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-sack-immediately-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Ruediger.Geib@telekom.de Tue Feb 19 00:32:18 2013 Return-Path: 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 845EA21F8634 for ; Tue, 19 Feb 2013 00:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPYP+8ZlsEgz for ; Tue, 19 Feb 2013 00:32:16 -0800 (PST) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id B864B21F85E7 for ; Tue, 19 Feb 2013 00:32:11 -0800 (PST) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 19 Feb 2013 09:32:10 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 19 Feb 2013 09:32:09 +0100 From: To: , Date: Tue, 19 Feb 2013 09:32:08 +0100 Thread-Topic: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalizer-00.txt Thread-Index: Ac4GcBXrNOtmIMweTbifdbQEwQJH6QFPqcaQALKPqnA= Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: wenywang@cisco.com, stanyang@cisco.com, eckert@cisco.com, fyip@cisco.com Subject: Re: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalizer-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:32:18 -0000 Hi CJ, an important assumption for the draft to work seems to be video layer infor= mation availability, as AF PHBs are proposed to be assigned to a stream bas= ed on aggregate video flow frame properties. To gain this information, a vi= deo flow must not be encrypted and DPI may be applicable. The normalisation= suggests to treat all flows equally in terms of percentage of assigned AF = PHBs within a single AF class. I'm working for a network provider and I'm not sure whether the approach wo= uld add sufficient value to a QoS based streaming service to justify the ef= fort required. Might it be simpler to leave AF class PHB percentages to SLA= s and accounting agreements between CDNs and network providers? In that cas= e, your draft may be relevant for CDNs. Regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of C= heng-Jia Lai (chelai) Sent: Friday, February 15, 2013 8:03 PM To: tsvwg@ietf.org Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); = Fred Yip (fyip) Subject: Re: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-norma= lizer-00.txt Hi folks, Will appreciate some comments on this new draft that we posted last week fo= r NM in AF PHB groups of DiffServ. Thanks, CJ -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of C= heng-Jia Lai (chelai) Sent: Friday, February 08, 2013 7:01 PM To: tsvwg@ietf.org Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); = Fred Yip (fyip) Subject: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalize= r-00.txt Hi all, We have submitted a new Internet draft to describe a Normalization Marker (= NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM = deployment is to create a new incentive for video encoders to generate more= discardable packets when using AF PHB in DIffServ. We are looking forward = to your review comments. Best regards, CJ -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, February 08, 2013 6:25 PM To: Cheng-Jia Lai (chelai) Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); = Fred Yip (fyip) Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt A new version of I-D, draft-lai-tsvwg-normalizer-00.txt has been successfully submitted by Cheng-Jia Lai and posted to the IETF repository. Filename: draft-lai-tsvwg-normalizer Revision: 00 Title: Normalization Marker for AF PHB Group in DiffServ Creation date: 2013-02-08 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normal= izer-00.txt Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 Abstract: This memo describes a Normalization Marker (NM) at DiffServ (DS) nodes to normalize the distribution of DS codepoint (DSCP) markings for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is useful for traffic conditioning with Active Queue Management (AQM) when the AF PHB group is deployed for multimedia service classes that carry video packets with advanced codec technologies. Using NM can offer an incentive that is however missing in today's ecosystem of practical deployment, i.e., when congestion occurs in the AF PHB group, the network should allow a video codec to benefit from its effort of generating finer layers of intra-flow precedence (IFP) with discardable packets in a more balanced distribution. The IETF Secretariat From internet-drafts@ietf.org Tue Feb 19 00:34:29 2013 Return-Path: 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 621B821F871F; Tue, 19 Feb 2013 00:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zc3y8Re2jhKH; Tue, 19 Feb 2013 00:34:29 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFCA21F869C; Tue, 19 Feb 2013 00:34:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130219083428.19459.75435.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 00:34:28 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-app-id-vv-profiles-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 08:34:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Resource Reservation Protocol (RSVP) Application-ID Prof= iles for Voice and Video Streams Author(s) : James Polk Subha Dhesikan Filename : draft-ietf-tsvwg-rsvp-app-id-vv-profiles-00.txt Pages : 15 Date : 2013-02-18 Abstract: RFC 2872 defines an Resource Reservation Protocol (RSVP) object for application identifiers. This document uses that App-ID and gives implementers specific guidelines for differing voice and video stream identifications to nodes along a reservation path, creating specific profiles for voice and video session identification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-app-id-vv-profiles There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-app-id-vv-profiles-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Feb 19 02:37:28 2013 Return-Path: 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 AAD5721F8CC9; Tue, 19 Feb 2013 02:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3NUHBm-W56K; Tue, 19 Feb 2013 02:37:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0372F21F8CC8; Tue, 19 Feb 2013 02:37:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130219103728.8201.91750.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 02:37:28 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-10.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 10:37:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : UDP Encapsulation of SCTP Packets for End-Host to End-Ho= st Communication Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-10.txt Pages : 11 Date : 2013-02-19 Abstract: This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. Please note that this document does not provide all techniques necessary for building a complete NAT-capable application using SCTP. This document focuses on the functionality required within the SCTP stack and making this available via an API. It does not cover mechanism to determine whether UDP encapsulation is required to reach the peer and, if UDP encapsulation is used, which remote UDP port number can be used. This document covers only end-hosts and not tunneling (egress or ingress) end-points. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-udp-encaps-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gorry@erg.abdn.ac.uk Tue Feb 19 08:22:54 2013 Return-Path: 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 A04F521F8B83 for ; Tue, 19 Feb 2013 08:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqfZ0h7cBhp6 for ; Tue, 19 Feb 2013 08:22:53 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id B54CD21F8A3E for ; Tue, 19 Feb 2013 08:22:53 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id F111B2B43C1; Tue, 19 Feb 2013 16:22:51 +0000 (GMT) Received: from 78.40.152.129 (proxying for 10.114.98.230) (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 19 Feb 2013 16:22:51 -0000 Message-ID: Date: Tue, 19 Feb 2013 16:22:51 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tsvwg-chairs@tools.ietf.org Subject: [tsvwg] TSVWG Agenda for Orlando, IETF 86 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:22:54 -0000 TSVWG has two slots allocated for Orlando. If you have a draft you would like to discuss and have not yet informed us, please send your request for agenda time to the tsvwg chairs (tsvwg-chairs@ietf.org). Please include in the request, the title and file name of the draft, the speaker's name (and email), and how much time you think you will need. We will prioritise drafts that are working group items and drafts that have been actively discussed on the list. New drafts not discussed on the mailing list prior to the meeting, or drafts that do not appear to have support from the working group are unlikely to get time at the meeting. Regards, Gorry, James & David (TSVWG Co-Chairs) From internet-drafts@ietf.org Tue Feb 19 08:40:32 2013 Return-Path: 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 7D55221F8E06; Tue, 19 Feb 2013 08:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPnd+Jw1ICHg; Tue, 19 Feb 2013 08:40:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E704A21F8C17; Tue, 19 Feb 2013 08:40:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130219164031.27762.93280.idtracker@ietfa.amsl.com> Date: Tue, 19 Feb 2013 08:40:31 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-sctp-udp-encaps-11.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:40:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : UDP Encapsulation of SCTP Packets for End-Host to End-Ho= st Communication Author(s) : Michael Tuexen Randall R. Stewart Filename : draft-ietf-tsvwg-sctp-udp-encaps-11.txt Pages : 11 Date : 2013-02-19 Abstract: This document describes a simple method of encapsulating SCTP Packets into UDP packets and its limitations. This allows the usage of SCTP in networks with legacy NAT not supporting SCTP. It can also be used to implement SCTP on hosts without directly accessing the IP-layer, for example implementing it as part of the application without requiring special privileges. Please note that this document does not provide all techniques necessary for building a complete NAT-capable application using SCTP. This document focuses on the functionality required within the SCTP stack and making this available via an API. It does not cover mechanism to determine whether UDP encapsulation is required to reach the peer and, if UDP encapsulation is used, which remote UDP port number can be used. This document covers only end-hosts and not tunneling (egress or ingress) end-points. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-udp-encaps There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-udp-encaps-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-sctp-udp-encaps-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lucy.yong@huawei.com Wed Feb 20 12:19:16 2013 Return-Path: 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 59BC021F889C for ; Wed, 20 Feb 2013 12:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49jBqTYr2p1n for ; Wed, 20 Feb 2013 12:19:15 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3EF21F87C6 for ; Wed, 20 Feb 2013 12:19:14 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOQ40955; Wed, 20 Feb 2013 20:19:13 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 20 Feb 2013 20:18:26 +0000 Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 21 Feb 2013 04:19:12 +0800 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.007; Wed, 20 Feb 2013 12:19:02 -0800 From: Lucy yong To: "gorry@erg.abdn.ac.uk" , Joe Touch Thread-Topic: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt Thread-Index: Ac4KL8IgAoSRO8SCR92SMikBdytxFQACxZxAABG/14AAEIvvQP//ltUA//+VAVCAAYkugIABmSiAgABsvTD//8fOAIAAxJKA//mB1gA= Date: Wed, 20 Feb 2013 20:19:01 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D448948F5@dfweml505-mbx> References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> <511C3356.40208@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> <511D2367.4060105@isi.edu> <511E7AA1.6090905@erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D44891B91@dfweml505-mbx> <511EA6B4.7030509@isi.edu> <59633c251a788b87970555742a1bd7e3.squirrel@www.erg.abdn.ac.uk> In-Reply-To: <59633c251a788b87970555742a1bd7e3.squirrel@www.erg.abdn.ac.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.87.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "vishwas.manral@hp.com" , 'John E Drake' , 'Edward Crabbe' , "tsvwg@ietf.org" , "'Carlos Pignataro \(cpignata\)'" , "nsheth@contrailsystems.com" , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:19:16 -0000 Gorry, Please see inline. > -----Original Message----- > From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] > Sent: Saturday, February 16, 2013 3:04 AM > To: Joe Touch > Cc: Lucy yong; gorry@erg.abdn.ac.uk; vishwas.manral@hp.com; 'Edward > Crabbe'; tsvwg@ietf.org; 'John E Drake'; 'Carlos Pignataro (cpignata)'; > nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu > Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- > encap-4-ip-tunneling-00.txt >=20 > Hi, >=20 > Some more thoughts on port usage: >=20 > I would like to understand whether we REALLY need a separate > destination > port per protocol. I think that it would relatively easy to use a > header > byte in the payload to differentiate tunnel control messages and > tunnelled > (encapsulated) IP packets. If you do this, wouldn't it be possible to > run > over one port. GRE, for example, runs over one IP codepoint. [Lucy] Theoretically, we can do that way, i.e. implementing a shim at tunne= l end point. But many existing hardware are not able to do that, it may int= erfere with other existing shims. Since you did not mean the following in your previous mail, I interpreted y= ou wrong. Let's take this off table now. Regards, Lucy >=20 > When you talk about the source port reflecting payload type, were you > suggesting a tunnel control protocol negotiates using a setup packet > what > protocol is being used? - that seems a possibility with each (src,dst) > pair being dynamically transported protocol? (or have I misunderstood?) >=20 > On the source port, I was expecting that each "tunnel" could have one > source port. I'm not clear of your use cases, are we expecting multiple > associations to the same destination that want to use with ECMP for > example? in which case, this seems it would imply multiple src ports in > use from the same sender, allowing each to be independently be routed? > (This was why I mentioned "entropy" for ECMP). >=20 > Gorry >=20 > > Hi, Lucy (et al.), > > > > On 2/15/2013 12:11 PM, Lucy yong wrote: > > ... > >> We thank Joe for the comments and guideline about UDP port > >> assignment rule. Src port have 16 bits. Do you suggest using the src > >> port for both entropy and payload type? > > > > Source port helps differentiate different streams between two IP > > endpoints to the same service, but I would not strictly call that > > "entropy". It can be useful to keep flows separate, as Gorry noted, > and > > can indicate a flow type *after* some other mechanism (in band or out > of > > band) provides initial information of the flow type - that way you > can > > avoid needing to send a shim layer in every payload. > > > > The source port cannot be used as payload type. Depending on your > view, > > either you can't reserve them at all or they are reserved by the same > > IANA process as destination ports (I've heard both arguments, but > > without going into detail they're equivalent here - the source port > > isn't useful as a known quantity). > > > > Joe > > >=20 From touch@isi.edu Wed Feb 20 12:50:55 2013 Return-Path: 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 A151D21E8039 for ; Wed, 20 Feb 2013 12:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.026 X-Spam-Level: X-Spam-Status: No, score=-103.026 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPYzTqCxA3H2 for ; Wed, 20 Feb 2013 12:50:55 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1A74821E8037 for ; Wed, 20 Feb 2013 12:50:55 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-87-221.lsanca.dsl-w.verizon.net [71.105.87.221]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1KKo2sh023621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Feb 2013 12:50:12 -0800 (PST) Message-ID: <512536FC.6000101@isi.edu> Date: Wed, 20 Feb 2013 12:50:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lucy yong References: <05a901ce0a2f$c9176f60$5b464e20$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D448913A5@dfweml505-mbx> <511C1C83.8040103@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D448913EA@dfweml505-mbx> <511C3356.40208@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D44891515@dfweml505-mbx> <511D2367.4060105@isi.edu> <511E7AA1.6090905@erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D44891B91@dfweml505-mbx> <511EA6B4.7030509@isi.edu> <59633c251a788b87970555742a1bd7e3.squirrel@www.erg.abdn.ac.uk> <2691CE0099834E4A9C5044EEC662BB9D448948F5@dfweml505-mbx> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D448948F5@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "gorry@erg.abdn.ac.uk" , "vishwas.manral@hp.com" , 'Edward Crabbe' , "tsvwg@ietf.org" , "'Carlos Pignataro \(cpignata\)'" , "nsheth@contrailsystems.com" , 'John E Drake' , "fanyb@gsta.com" , "'Lee, Yiu'" , Xuxiaohu Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp-encap-4-ip-tunneling-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:50:55 -0000 On 2/20/2013 12:19 PM, Lucy yong wrote: > Gorry, > > Please see inline. > >> -----Original Message----- >> From: gorry@erg.abdn.ac.uk [mailto:gorry@erg.abdn.ac.uk] >> Sent: Saturday, February 16, 2013 3:04 AM >> To: Joe Touch >> Cc: Lucy yong; gorry@erg.abdn.ac.uk; vishwas.manral@hp.com; 'Edward >> Crabbe'; tsvwg@ietf.org; 'John E Drake'; 'Carlos Pignataro (cpignata)'; >> nsheth@contrailsystems.com; fanyb@gsta.com; 'Lee, Yiu'; Xuxiaohu >> Subject: Re: [tsvwg] New Version Notification for draft-yong-tsvwg-udp- >> encap-4-ip-tunneling-00.txt >> >> Hi, >> >> Some more thoughts on port usage: >> >> I would like to understand whether we REALLY need a separate >> destination >> port per protocol. I think that it would relatively easy to use a >> header >> byte in the payload to differentiate tunnel control messages and >> tunnelled >> (encapsulated) IP packets. If you do this, wouldn't it be possible to >> run >> over one port. GRE, for example, runs over one IP codepoint. > [Lucy] Theoretically, we can do that way, i.e. implementing a shim at tunnel end point. But many existing hardware are not able to do that, it may interfere with other existing shims. > > Since you did not mean the following in your previous mail, I interpreted you wrong. Let's take this off table now. Can you explain? Existing hardware won't support any new port number assignments anyway. Adding a field for demultiplexing is trivial given the other requirements. Joe > > Regards, > Lucy >> >> When you talk about the source port reflecting payload type, were you >> suggesting a tunnel control protocol negotiates using a setup packet >> what >> protocol is being used? - that seems a possibility with each (src,dst) >> pair being dynamically transported protocol? (or have I misunderstood?) >> >> On the source port, I was expecting that each "tunnel" could have one >> source port. I'm not clear of your use cases, are we expecting multiple >> associations to the same destination that want to use with ECMP for >> example? in which case, this seems it would imply multiple src ports in >> use from the same sender, allowing each to be independently be routed? >> (This was why I mentioned "entropy" for ECMP). >> >> Gorry >> >>> Hi, Lucy (et al.), >>> >>> On 2/15/2013 12:11 PM, Lucy yong wrote: >>> ... >>>> We thank Joe for the comments and guideline about UDP port >>>> assignment rule. Src port have 16 bits. Do you suggest using the src >>>> port for both entropy and payload type? >>> >>> Source port helps differentiate different streams between two IP >>> endpoints to the same service, but I would not strictly call that >>> "entropy". It can be useful to keep flows separate, as Gorry noted, >> and >>> can indicate a flow type *after* some other mechanism (in band or out >> of >>> band) provides initial information of the flow type - that way you >> can >>> avoid needing to send a shim layer in every payload. >>> >>> The source port cannot be used as payload type. Depending on your >> view, >>> either you can't reserve them at all or they are reserved by the same >>> IANA process as destination ports (I've heard both arguments, but >>> without going into detail they're equivalent here - the source port >>> isn't useful as a known quantity). >>> >>> Joe >>> >> > From chelai@cisco.com Wed Feb 20 17:13:34 2013 Return-Path: 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 161D521F8686 for ; Wed, 20 Feb 2013 17:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, GB_MUTUALBENEFIT=2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aw1+pO5NDaLL for ; Wed, 20 Feb 2013 17:13:33 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B5C9921F8681 for ; Wed, 20 Feb 2013 17:13:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5244; q=dns/txt; s=iport; t=1361409212; x=1362618812; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=ChpUwJ781N/EIGuAizpVOgyXy5azp5CYH+GbTyT94zY=; b=FJxiBB9PY3cxWzmiaPAbT1d3SmFq0mZ4bzgKfqwHq8TtY0Qv50OIpFtR wDhkhHMMqvTKu747sQb6KifagbCnzJdxs2m608LHbk3SCOpVdcLV4Yn59 AA4jSUXUctq1IYtlEigkAz7YONX0O5c09MvugtYcLqZlsc7QHwU4+Zaee o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADR0JVGtJXHA/2dsb2JhbABFwFmBBBZzgh8BAQEEOisHCgECDAYBCBEEAQELFAk5FAgBCQEEAQ0FCAGICQzAM45dJgsNgllhA5dJjz6DB4In X-IronPort-AV: E=Sophos;i="4.84,705,1355097600"; d="scan'208";a="179380883" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 21 Feb 2013 01:13:32 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1L1DWeO015428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Feb 2013 01:13:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 20 Feb 2013 19:13:31 -0600 From: "Cheng-Jia Lai (chelai)" To: "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" Thread-Topic: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalizer-00.txt Thread-Index: Ac4P0KUzC4Q+aGE0TrqRa0Ho640R6w== Date: Thu, 21 Feb 2013 01:13:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.154.161.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Wenyi Wang \(wenywang\)" , "Stan Yang \(stanyang\)" , "Toerless Eckert \(eckert\)" , "Fred Yip \(fyip\)" Subject: Re: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalizer-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:13:34 -0000 Hi Ruediger, Thanks a lot for your comments. If NM operates in "color-aware" mode, it does not require video-layer infor= mation. Only if NM operates in "color-blind" mode will it require availabil= ity of video layer information. Thus, if video is encrypted, color-aware NM= can be used. It is true that color-blind NM will need more efforts in determining IFP pe= r packet since it doesn't rely on the existing AF markings as color-aware N= M does. I agree that a network provider can justify if it is worth using co= lor-blind NM; if not, just deploy color-aware NM at the DS boundary. Indeed, AF PHB group defines SLA between a network provider and its users (= e.g. CDN, enterprise VPN, etc.), and it is not our place to re-define that = with this draft. Our intention with NM is just to offer a tool that a netwo= rk provider can deploy to encourage its users to employ better video encode= rs that will generate more discardable video packets, for the mutual benefi= ts. Regards, CJ -----Original Message----- From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de]=20 Sent: Tuesday, February 19, 2013 12:32 AM To: Cheng-Jia Lai (chelai); tsvwg@ietf.org Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); = Fred Yip (fyip) Subject: RE: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-norma= lizer-00.txt Hi CJ, an important assumption for the draft to work seems to be video layer infor= mation availability, as AF PHBs are proposed to be assigned to a stream bas= ed on aggregate video flow frame properties. To gain this information, a vi= deo flow must not be encrypted and DPI may be applicable. The normalisation= suggests to treat all flows equally in terms of percentage of assigned AF = PHBs within a single AF class. I'm working for a network provider and I'm not sure whether the approach wo= uld add sufficient value to a QoS based streaming service to justify the ef= fort required. Might it be simpler to leave AF class PHB percentages to SLA= s and accounting agreements between CDNs and network providers? In that cas= e, your draft may be relevant for CDNs. Regards, Ruediger -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of C= heng-Jia Lai (chelai) Sent: Friday, February 15, 2013 8:03 PM To: tsvwg@ietf.org Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); = Fred Yip (fyip) Subject: Re: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-norma= lizer-00.txt Hi folks, Will appreciate some comments on this new draft that we posted last week fo= r NM in AF PHB groups of DiffServ. Thanks, CJ -----Original Message----- From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] On Behalf Of C= heng-Jia Lai (chelai) Sent: Friday, February 08, 2013 7:01 PM To: tsvwg@ietf.org Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); = Fred Yip (fyip) Subject: [tsvwg] FW: New Version Notification for draft-lai-tsvwg-normalize= r-00.txt Hi all, We have submitted a new Internet draft to describe a Normalization Marker (= NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM = deployment is to create a new incentive for video encoders to generate more= discardable packets when using AF PHB in DIffServ. We are looking forward = to your review comments. Best regards, CJ -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, February 08, 2013 6:25 PM To: Cheng-Jia Lai (chelai) Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); = Fred Yip (fyip) Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt A new version of I-D, draft-lai-tsvwg-normalizer-00.txt has been successfully submitted by Cheng-Jia Lai and posted to the IETF repository. Filename: draft-lai-tsvwg-normalizer Revision: 00 Title: Normalization Marker for AF PHB Group in DiffServ Creation date: 2013-02-08 WG ID: Individual Submission Number of pages: 15 URL: http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normal= izer-00.txt Status: http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer Htmlized: http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00 Abstract: This memo describes a Normalization Marker (NM) at DiffServ (DS) nodes to normalize the distribution of DS codepoint (DSCP) markings for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group. NM is useful for traffic conditioning with Active Queue Management (AQM) when the AF PHB group is deployed for multimedia service classes that carry video packets with advanced codec technologies. Using NM can offer an incentive that is however missing in today's ecosystem of practical deployment, i.e., when congestion occurs in the AF PHB group, the network should allow a video codec to benefit from its effort of generating finer layers of intra-flow precedence (IFP) with discardable packets in a more balanced distribution. The IETF Secretariat From jmpolk@cisco.com Wed Feb 20 20:43:51 2013 Return-Path: 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 179BB21F8DC1 for ; Wed, 20 Feb 2013 20:43:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGZLTlPgxoBd for ; Wed, 20 Feb 2013 20:43:50 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 893D421F8DC7 for ; Wed, 20 Feb 2013 20:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=970; q=dns/txt; s=iport; t=1361421829; x=1362631429; h=message-id:date:to:from:subject:cc:mime-version; bh=36Mzs9vdbHwlivOTXs2qncbsuvf20iSxtJ4GIfFWmak=; b=fBzD9vaK7bs3Tt0NAcseBPxKVotF8EQmIPIWyKJA+K3lVW3o/X9PqQzL 5JcausCsaPCFJtYj5DD2uCo4iS3Xq7qvONWMKcWSBWGRibTD4lQlsb4Og jS7Kg8ra/JH9wXz37MNnxhy62qY1wTUD/s/iVTyJpv/wZm5UpBwam2Jxn w=; X-IronPort-AV: E=Sophos;i="4.84,706,1355097600"; d="scan'208";a="179447446" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 21 Feb 2013 04:43:49 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1L4hmow009860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 04:43:49 GMT Message-Id: <201302210443.r1L4hmow009860@rcdn-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 20 Feb 2013 22:43:48 -0600 To: "Subha Dhesikan (sdhesika)" , ken carlberg , lberger@labn.net, Fred Baker From: James Polk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: tsvwg@ietf.org Subject: [tsvwg] Choosing the Option for MULTI_INSTANCE Object...? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:43:51 -0000 I haven't gotten much feedback to the central question I posed the WG in Atlanta, but I guess it's my fault for taking so long to write this new draft. I'm referring to the draft at http://www.ietf.org/internet-drafts/draft-polk-rsvp-multi-instance-object-00.txt If you don't want ASCII art (and who does really?), view the preso for it at http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-14.pdf The choice I'm referring to is on slide 4, about the construction of the Object that includes multiple instances of other *SPECs, elements and/or Objects so RSVP can be more efficient, and doesn't have to go through several iterations of PATH followed by PATH_Err (or ResvErr) before figuring out settling in on a reservation with an acceptable set up parameters. In Atlanta, the room felt as though Option 1 (the middle one) was best. I would like to hear from a larger number of folks on this list. James (with my author hat on) From iesg-secretary@ietf.org Thu Feb 21 08:21:39 2013 Return-Path: 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 682DC21F8EEE; Thu, 21 Feb 2013 08:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ2OaAGjfCUn; Thu, 21 Feb 2013 08:21:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4614121F8EE6; Thu, 21 Feb 2013 08:21:37 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130221162137.31566.7988.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 08:21:37 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] Last Call: (Byte and Packet Congestion Notification) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:21:40 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Byte and Packet Congestion Notification' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides recommendations of best current practice for dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre-congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Thu Feb 21 08:21:41 2013 Return-Path: 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 B6D8C21F8EEE for ; Thu, 21 Feb 2013 08:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH94z71FhcYw; Thu, 21 Feb 2013 08:21:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C73C21F8EEC; Thu, 21 Feb 2013 08:21:38 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-tsvwg-byte-pkt-congest X-IETF-Draft-revision: 09 Message-ID: <20130221162138.31566.30873.idtracker@ietfa.amsl.com> Date: Thu, 21 Feb 2013 08:21:38 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] Last Call: (Byte and Packet Congestion Notification) to Best Current Practice X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 16:21:41 -0000 The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Byte and Packet Congestion Notification' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-03-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document provides recommendations of best current practice for dropping or marking packets using active queue management (AQM) such as random early detection (RED) or pre-congestion notification (PCN). We give three strong recommendations: (1) packet size should be taken into account when transports read and respond to congestion indications, (2) packet size should not be taken into account when network equipment creates congestion signals (marking, dropping), and therefore (3) the byte-mode packet drop variant of the RED AQM algorithm that drops fewer small packets should not be used. This memo updates RFC 2309 to deprecate deliberate preferential treatment of small packets in AQM algorithms. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tsvwg-byte-pkt-congest/ballot/ No IPR declarations have been submitted directly on this I-D. From jmpolk@cisco.com Thu Feb 21 11:48:53 2013 Return-Path: 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 4DD3921F8EF2 for ; Thu, 21 Feb 2013 11:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rE2sj37MGO0o for ; Thu, 21 Feb 2013 11:48:52 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6D18521F88C8 for ; Thu, 21 Feb 2013 11:48:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1617; q=dns/txt; s=iport; t=1361476125; x=1362685725; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=6YrSEHpMaEI/yUla+2fu8Eio0qu/hva3OstVXEJEJVg=; b=EJY9QtviO6lxwPgxSs8tqIEA6+zgC3lXGctDGhiCoPKShsf69GFHsBGS ev1e+5WxKUhmJPk3Wk9zZC0hcFVlWrSQzQHxXPIl3xq7iL+wt5yQlmlR8 KWJMsr7+kc05viZiYCnEoxIg3RtmITKry34fPEOBC7Czv1grBsbrJfzxh w=; X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179812230" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 21 Feb 2013 19:48:45 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8717.cisco.com [10.99.80.24]) (authenticated bits=0) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1LJmi7M014928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2013 19:48:45 GMT Message-Id: <201302211948.r1LJmi7M014928@rcdn-core-6.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Feb 2013 13:48:44 -0600 To: "Subha Dhesikan (sdhesika)" , ken carlberg , , Fred Baker From: James Polk In-Reply-To: <201302210443.r1L4hmow009860@rcdn-core-1.cisco.com> References: <201302210443.r1L4hmow009860@rcdn-core-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: tsvwg@ietf.org Subject: Re: [tsvwg] Choosing the Option for MULTI_INSTANCE Object...? X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:48:53 -0000 BTW - another option is to *not* attempt to bundle/group multiple instances of RSVP *SPECS or elements or objects and simply progress eachone at a time, with the first being the WG item draft-ietf-tsvwg-intserv-multiple-tspec handling multiple the need for TSPECs. draft-polk-rsvp-multi-instance-object was written because someone else thought grouping was valuable, and I agreed to write it. We don't have to do this grouping effort, if that's what the WG wants (or is that "if that's *not* what the WG wants to do"). James (with my author hat on) At 10:43 PM 2/20/2013, James Polk wrote: >I haven't gotten much feedback to the central question I posed the >WG in Atlanta, but I guess it's my fault for taking so long to write >this new draft. I'm referring to the draft at > >http://www.ietf.org/internet-drafts/draft-polk-rsvp-multi-instance-object-00.txt > >If you don't want ASCII art (and who does really?), view the preso for it at >http://www.ietf.org/proceedings/85/slides/slides-85-tsvwg-14.pdf > >The choice I'm referring to is on slide 4, about the construction of >the Object that includes multiple instances of other *SPECs, >elements and/or Objects so RSVP can be more efficient, and doesn't >have to go through several iterations of PATH followed by PATH_Err >(or ResvErr) before figuring out settling in on a reservation with >an acceptable set up parameters. > >In Atlanta, the room felt as though Option 1 (the middle one) was >best. I would like to hear from a larger number of folks on this list. > >James >(with my author hat on) From touch@isi.edu Fri Feb 22 15:10:32 2013 Return-Path: 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 822DA21E808C for ; Fri, 22 Feb 2013 15:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103 X-Spam-Level: X-Spam-Status: No, score=-103 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2CKDRVGkapA for ; Fri, 22 Feb 2013 15:10:22 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 86A1E21F890D for ; Fri, 22 Feb 2013 15:10:19 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id r1MN9hqd008237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 22 Feb 2013 15:09:44 -0800 (PST) Message-ID: <5127FAAF.6090507@isi.edu> Date: Fri, 22 Feb 2013 15:09:35 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: tsvwg-chairs@tools.ietf.org, tsvwg@ietf.org Subject: Re: [tsvwg] TSVWG Agenda for Orlando, IETF 86 X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 23:10:32 -0000 FYI - I just submitted an update to draft-ietf-tsvwg-port-use It incorporates all feedback from the last meeting, as well as the discussion of user vs. system ports. I can prepare a summary if someone can present it, if useful. This version has reasonably complete text now (it's not just an outline). Joe On 2/19/2013 8:22 AM, gorry@erg.abdn.ac.uk wrote: > TSVWG has two slots allocated for Orlando. > > If you have a draft you would like to discuss and have not yet informed > us, please send your request for agenda time to the tsvwg chairs > (tsvwg-chairs@ietf.org). > > Please include in the request, the title and file name of the draft, the > speaker's name (and email), and how much time you think you will need. > > We will prioritise drafts that are working group items and drafts that > have been actively discussed on the list. New drafts not discussed on the > mailing list prior to the meeting, or drafts that do not appear to have > support from the working group are unlikely to get time at the meeting. > > Regards, > > Gorry, James & David > (TSVWG Co-Chairs) > From internet-drafts@ietf.org Sun Feb 24 08:12:57 2013 Return-Path: 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 9E01821F84F9; Sun, 24 Feb 2013 08:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqn2Lyoq17eO; Sun, 24 Feb 2013 08:12:57 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45A021F8549; Sun, 24 Feb 2013 08:12:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130224161256.2140.66206.idtracker@ietfa.amsl.com> Date: Sun, 24 Feb 2013 08:12:56 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 16:12:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Generic Aggregation of Resource ReSerVation Protocol (RS= VP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-04.txt Pages : 27 Date : 2013-02-24 Abstract: This document specifies extensions to Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From karagian@cs.utwente.nl Sun Feb 24 08:23:20 2013 Return-Path: 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 D887F21F8F76; Sun, 24 Feb 2013 08:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPIF9pVm-ZN6; Sun, 24 Feb 2013 08:23:20 -0800 (PST) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id D9CDA21F8F9F; Sun, 24 Feb 2013 08:23:19 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sun, 24 Feb 2013 17:23:18 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.16]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Sun, 24 Feb 2013 17:23:18 +0100 From: To: , Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-04.txt Thread-Index: AQHOEqnhLmV/S3ihLUGvW5FEdTklU5iJLy2JgAACACI= Date: Sun, 24 Feb 2013 16:23:17 +0000 Message-ID: References: <20130224161256.2140.66206.idtracker@ietfa.amsl.com> In-Reply-To: <20130224161256.2140.66206.idtracker@ietfa.amsl.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36ACC2EXMBX23adutwent_" MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-04.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 16:23:21 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36ACC2EXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, A new version of the draft-ietf-tsvwg-rsvp-pcn has been submitted! All comments provided by Ken and Lixia have been worked out! Several comments provided by Bob have been worked out. More details on this= issue will be provided before the IETF meeting. The proposal of Francois on motivating the appliance of RFC4860 in PCN have= been incorporated in Section 1.2 (Overview and Motivation). Best regards, Georgios ________________________________ Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens internet-drafts= @ietf.org [internet-drafts@ietf.org] Verzonden: zondag 24 februari 2013 17:12 To: i-d-announce@ietf.org Cc: tsvwg@ietf.org Onderwerp: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Generic Aggregation of Resource ReSerVation Proto= col (RSVP) for IPv4 And IPv6 Reservations over PCN domains Author(s) : Georgios Karagiannis Anurag Bhargava Filename : draft-ietf-tsvwg-rsvp-pcn-04.txt Pages : 27 Date : 2013-02-24 Abstract: This document specifies extensions to Generic Aggregated RSVP [RFC4860] for support of the PCN Controlled Load (CL) and Single Marking (SM) edge behaviors over a Diffserv cloud using Pre- Congestion Notification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp-pcn-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36ACC2EXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4A8DA167A7AA244193F6C2DC4A3B38A5@exchange.utwente.nl> Content-Transfer-Encoding: quoted-printable

Hi all,

 

A new version of the draft-ietf-tsvwg-rsvp-pcn has been submitted!

All comments provided by Ken and Lixia have been worked out!

 

Several comments provided by Bob have been worked out. More details on t= his issue will be provided before the

IETF meeting.

 

The proposal of Francois on motivating the appliance of RFC4860 in = PCN have been incorporated in Section 1.2 (Overview and Motivation).

 

Best regards,

Georgios

 

 

 

Van: tsvwg-bounces@ietf.org [tsvwg-bounces@ietf.org] namens inte= rnet-drafts@ietf.org [internet-drafts@ietf.org]
Verzonden: zondag 24 februari 2013 17:12
To: i-d-announce@ietf.org
Cc: tsvwg@ietf.org
Onderwerp: [tsvwg] I-D Action: draft-ietf-tsvwg-rsvp-pcn-04.txt


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
 This draft is a work item of the Transport Area Working Group Working= Group of the IETF.

        Title    &nb= sp;      : Generic Aggregation of Resource ReSerVa= tion Protocol (RSVP) for IPv4 And IPv6 Reservations over PCN domains
        Author(s)    = ;   : Georgios Karagiannis
            &nb= sp;            = Anurag Bhargava
        Filename    =     : draft-ietf-tsvwg-rsvp-pcn-04.txt
        Pages    &nb= sp;      : 27
        Date    &nbs= p;       : 2013-02-24

Abstract:
   This document specifies extensions to Generic Aggregated RSVP<= br>    [RFC4860] for support of the PCN Controlled Load (CL) and Sing= le
   Marking (SM) edge behaviors over a Diffserv cloud using Pre-    Congestion Notification.





The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rsvp-pcn

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tsvwg-rsvp-pcn-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-rsvp= -pcn-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F36ACC2EXMBX23adutwent_-- From Ruediger.Geib@telekom.de Mon Feb 25 04:41:39 2013 Return-Path: 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 99FEE21F92F8 for ; Mon, 25 Feb 2013 04:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNFaWQKc4jMY for ; Mon, 25 Feb 2013 04:41:39 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id BDCEE21F92F2 for ; Mon, 25 Feb 2013 04:41:33 -0800 (PST) Received: from he111628.emea1.cds.t-internal.com ([10.134.93.20]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 25 Feb 2013 13:41:32 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE111628.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 25 Feb 2013 13:41:32 +0100 From: To: Date: Mon, 25 Feb 2013 13:41:30 +0100 Thread-Topic: New version notification draft-geib-tsvwg-diffserv-intercon-02.txt Thread-Index: Ac4TSjIrWVcoB5h5Q2+YBmDr3UIOBgACJ1Jw Message-ID: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] New version notification draft-geib-tsvwg-diffserv-intercon-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 12:41:39 -0000 Hello, below you'll find the links to a revised version of the DiffServ intreconnection scheme. I forgot some references in version -01, so I added a version -02 before cutoff. To simplify comparing it with -00, here's a diff -00 vs. -02: http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-geib-ts= vwg-diffserv-intercon-00.txt&url2=3Dhttp://tools.ietf.org/id/draft-geib-tsv= wg-diffserv-intercon-02.txt Regards, Ruediger -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, February 25, 2013 12:20 PM To: Geib, R=FCdiger Subject: New Version Notification for draft-geib-tsvwg-diffserv-intercon-02= .txt A new version of I-D, draft-geib-tsvwg-diffserv-intercon-02.txt has been successfully submitted by Ruediger Geib and posted to the IETF repository. Filename: draft-geib-tsvwg-diffserv-intercon Revision: 02 Title: DiffServ interconnection classes and practice Creation date: 2013-02-25 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-geib-tsvwg-diffs= erv-intercon-02.txt Status: http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-= intercon Htmlized: http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-inter= con-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-geib-tsvwg-diffse= rv-intercon-02 Abstract: This document proposes a limited set of interconnection QoS PHBs and PHB groups. It further introduces some DiffServ deployment aspects. The proposals made here should be integrated into a revised version of RFC5127. From mohamed.boucadair@orange.com Mon Feb 25 06:07:18 2013 Return-Path: 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 30F6221F9328 for ; Mon, 25 Feb 2013 06:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6C7MaEtX8qY for ; Mon, 25 Feb 2013 06:07:17 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 5C09C21F9327 for ; Mon, 25 Feb 2013 06:07:17 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 71AAE2DC24D; Mon, 25 Feb 2013 15:07:15 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 40D3027C0A7; Mon, 25 Feb 2013 15:07:15 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Mon, 25 Feb 2013 15:07:13 +0100 From: To: "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" Date: Mon, 25 Feb 2013 15:07:12 +0100 Thread-Topic: New version notification draft-geib-tsvwg-diffserv-intercon-02.txt Thread-Index: Ac4TSjIrWVcoB5h5Q2+YBmDr3UIOBgACJ1JwAAOdHYA= Message-ID: <94C682931C08B048B7A8645303FDC9F36EB3C82FE5@PUEXCB1B.nanterre.francetelecom.fr> References: In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.19.124517 Cc: LEVIS Pierre OLNC/OLPS , JACQUENET Christian OLNC/OLN Subject: Re: [tsvwg] New version notification draft-geib-tsvwg-diffserv-intercon-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:07:18 -0000 Dear Reuediger, Thank you for updating the draft. Below some additional comments and text p= roposal:=20 * The document mentions SLA without citing a reference. FWIW, you can cite = http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-profil= e-02. That document defines various performance guarantees clauses to be in= cluded in a connectivity agreement (can be used between two network provide= rs).=20 * You may add the following text to the introduction: The current practices in operational network is to reset DSCP to 0 in interconnection points. An ASBR does not trust the marking set by an external adjacent ASBR. This practice is likely to evolve if interconnection agreements are reviewed to include QoS performance guarantees. Those agreements may include in particular the marking policy to be enforced in the interconnection link. * I fully agree having a well defined set of classes will ease QoS intercon= nection practices (e.g., how to bound my classes to those of an adjacent do= main). Nevertheless, having standard codepoints assigned to those QoS class= es may be of less interest if we assume these values are agreed between adj= acent provided and are captured in an interconnection agreement. The text s= hould motivate further such need. You may add the following for instance: Having a limited set of codepoints for QoS interconnect are likely to accelerate network provisioning by providing generic policies to be enforced at the interconnection nodes. The use of standard code points ease automation of network interconnection agreement and settlement proc= edures. =20 * You may also add the following: Network providers may agree to use other codepoints than those defined in this document. =20 This document does not require network providers to expose their internal QoS configuration (e.g., number QoS classes, internal DSCP codepoints, classification policies, etc.). Cheers, Med =20 >-----Message d'origine----- >De : tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] De=20 >la part de Ruediger.Geib@telekom.de >Envoy=E9 : lundi 25 f=E9vrier 2013 13:42 >=C0 : tsvwg@ietf.org >Objet : [tsvwg] New version notification=20 >draft-geib-tsvwg-diffserv-intercon-02.txt > >Hello, > >below you'll find the links to a revised version of the DiffServ >intreconnection scheme. I forgot some references in version -01, >so I added a version -02 before cutoff. To simplify comparing >it with -00, here's a diff -00 vs. -02: > >http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/dra >ft-geib-tsvwg-diffserv-intercon-00.txt&url2=3Dhttp://tools.ietf.o >rg/id/draft-geib-tsvwg-diffserv-intercon-02.txt > >Regards, > >Ruediger > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, February 25, 2013 12:20 PM >To: Geib, R=FCdiger >Subject: New Version Notification for=20 >draft-geib-tsvwg-diffserv-intercon-02.txt > > >A new version of I-D, draft-geib-tsvwg-diffserv-intercon-02.txt >has been successfully submitted by Ruediger Geib and posted to the >IETF repository. > >Filename: draft-geib-tsvwg-diffserv-intercon >Revision: 02 >Title: DiffServ interconnection classes and practice >Creation date: 2013-02-25 >Group: Individual Submission >Number of pages: 12 >URL: =20 >http://www.ietf.org/internet-drafts/draft-geib-tsvwg-diffserv-i >ntercon-02.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon >Htmlized: =20 >http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-intercon-02 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-geib-tsvwg-diffserv-intercon-02 > >Abstract: > This document proposes a limited set of interconnection QoS PHBs and > PHB groups. It further introduces some DiffServ deployment aspects. > The proposals made here should be integrated into a revised version > of RFC5127. > > > > >= From svshah@cisco.com Mon Feb 25 08:55:59 2013 Return-Path: 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 9454F21F953B; Mon, 25 Feb 2013 08:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlYW-b47-IMU; Mon, 25 Feb 2013 08:55:58 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9552321F9525; Mon, 25 Feb 2013 08:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2389; q=dns/txt; s=iport; t=1361811358; x=1363020958; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ei6PXThpTNhDEpztQ47tLTW31+HvckfjvaaxdonEM+U=; b=Ky9J3VyH4M1jeBID8WtJvIsFLhvwnXan6s0Km7U5Z2sE7LstCYw7a/// LOUTImcauE30Tk1DY9+0CcN/GpqOcPVzSMS0FOoPDIZtNzNQy4b7ZMzIp ssRrb9CsMuzUEcNIHz4f1V3TAK4jEeRUt6HLQ+EnlF0CB4zD0rnjM5+Sk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHaWK1GtJXHA/2dsb2JhbABFwVWBBRZzgh8BAQEEOj0UAQgSEBRCFwQBBgMCBAESCAGICgy/L41OgQ84gl9hA5JChRiPSIFSgTWCJw X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208";a="180895511" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 25 Feb 2013 16:55:58 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1PGtw00003717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 16:55:58 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:55:57 -0600 From: "Shitanshu Shah (svshah)" To: "tsvwg@ietf.org" , "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: New Version Notification for draft-svshah-tsvwg-lln-diffserv-recommendations-00.txt Thread-Index: AQHOE3j7e3DE7qiuzkW77qu/KD41hw== Date: Mon, 25 Feb 2013 16:55:57 +0000 Message-ID: In-Reply-To: <20130218052624.23876.72337.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.21.70.77] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [tsvwg] FW: New Version Notification for draft-svshah-tsvwg-lln-diffserv-recommendations-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:55:59 -0000 Hi, Below is a revised version under re-named I-D, as was suggested by tsvwg chairs to have tsvwg in the draft name. Previous revision:=20 http://www.ietf.org/id/draft-svshah-lln-diffserv-recommendations-01.txt One of the discussion points in the last meeting, at Atlanta, was if to retain one of the existing code-point for Deterministic service class or define explicit one. Current revision, retains use of EF code-point for this service, anticipating mutually exclusive presence of Voice vs Deterministic class of traffic. However, PHB definition for this LLN class of traffic is more than just low latency (a definition used in classic networks). This has been highlighted in the draft. Any comments much appreciated.. Regards, Shitanshu On 2/17/13 9:26 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-svshah-tsvwg-lln-diffserv-recommendations-00.txt >has been successfully submitted by Shitanshu Shah and posted to the >IETF repository. > >Filename: draft-svshah-tsvwg-lln-diffserv-recommendations >Revision: 00 >Title: Differentiated Service Class Recommendations for LLN Traffic >Creation date: 2013-02-18 >Group: Individual Submission >Number of pages: 15 >URL: =20 >http://www.ietf.org/internet-drafts/draft-svshah-tsvwg-lln-diffserv-recomm >endations-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffserv-recommenda >tions >Htmlized: =20 >http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations >-00 > > >Abstract: > Differentiated services architecture is widely deployed in > traditional networks. There exist well defined recommendations for > the use of appropriate differentiated service classes for different > types of traffic (eg. audio, video) in these networks. Per-Hop > Behaviors are typically defined based on this recommendations. With > emerging Low-power and Lossy Networks (LLNs), it is important to have > similar defined differentiated services recommendations for LLN > traffic. Defined recommendations are for LLN class of traffic > exiting out of LLNs towards high-speed backbones, converged campus > network and for the traffic in the reverse direction. > > =20 > =20 > > >The IETF Secretariat > From internet-drafts@ietf.org Mon Feb 25 09:05:59 2013 Return-Path: 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 2600021F95DE; Mon, 25 Feb 2013 09:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6WN8Bqt5tfr; Mon, 25 Feb 2013 09:05:58 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4317321F95CF; Mon, 25 Feb 2013 09:05:57 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225170557.25596.27309.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 09:05:57 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:05:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Recommendations for Transport Port Uses Author(s) : Joe Touch Filename : draft-ietf-tsvwg-port-use-01.txt Pages : 16 Date : 2013-02-25 Abstract: This document provides recommendations to application and service designers on how to use the transport protocol port number space to help in its preservation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-port-use-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From touch@isi.edu Mon Feb 25 09:19:37 2013 Return-Path: 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 A77B821F9000 for ; Mon, 25 Feb 2013 09:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.419 X-Spam-Level: X-Spam-Status: No, score=-104.419 tagged_above=-999 required=5 tests=[AWL=0.888, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwNjOZRJ9enx for ; Mon, 25 Feb 2013 09:19:37 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 293BD21F8FB1 for ; Mon, 25 Feb 2013 09:19:37 -0800 (PST) Received: from [128.9.176.217] (c2-vpn05.isi.edu [128.9.176.217]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r1PHIbF0004942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 09:18:37 -0800 (PST) Message-ID: <512B9CF1.8030404@isi.edu> Date: Mon, 25 Feb 2013 09:18:41 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 CC: tsvwg References: <20130225170557.25596.27309.idtracker@ietfa.amsl.com> In-Reply-To: <20130225170557.25596.27309.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:19:37 -0000 Hi, all, This version includes: - results of the discussion of user vs. system ports - populates the previous sections that were just bullets It's a complete text version now. I'm still toying with the intro, and whether to move some of Sec 5 forward and some of the history later. Suggestions or comments are welcome. Thanks, Joe On 2/25/2013 9:05 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Area Working Group Working Group of the IETF. > > Title : Recommendations for Transport Port Uses > Author(s) : Joe Touch > Filename : draft-ietf-tsvwg-port-use-01.txt > Pages : 16 > Date : 2013-02-25 > > Abstract: > This document provides recommendations to application and service > designers on how to use the transport protocol port number space to > help in its preservation. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tsvwg-port-use-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-port-use-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From internet-drafts@ietf.org Mon Feb 25 11:45:11 2013 Return-Path: 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 C5E5221E80BB; Mon, 25 Feb 2013 11:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qyTmadVb7t0; Mon, 25 Feb 2013 11:45:09 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1379D21F8FAB; Mon, 25 Feb 2013 11:45:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225194509.21354.76781.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 11:45:09 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-intserv-multiple-tspec-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:45:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Integrated Services (IntServ) Extension to Allow Signali= ng of Multiple Traffic Specifications and Multiple Flow Specifications in R= SVPv1 Author(s) : James Polk Subha Dhesikan Filename : draft-ietf-tsvwg-intserv-multiple-tspec-02.txt Pages : 26 Date : 2013-02-25 Abstract: This document defines extensions to Integrated Services (IntServ) allowing multiple traffic specifications and multiple flow specifications to be conveyed in the same Resource Reservation Protocol (RSVPv1) reservation message exchange. This ability helps optimize an agreeable bandwidth through a network between endpoints in a single round trip. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-intserv-multiple-tspec There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-intserv-multiple-tspec-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-intserv-multiple-tspec-= 02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Feb 25 13:08:02 2013 Return-Path: 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 49EDA21F9291; Mon, 25 Feb 2013 13:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id othTYRXa0IWe; Mon, 25 Feb 2013 13:08:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F30621F9265; Mon, 25 Feb 2013 13:08:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225210801.10852.29186.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 13:08:01 -0800 Cc: tsvwg@ietf.org Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-natsupp-05.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 21:08:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Area Working Group Working Grou= p of the IETF. Title : Stream Control Transmission Protocol (SCTP) Network Addr= ess Translation Support Author(s) : Randall R. Stewart Michael Tuexen Irene Ruengeler Filename : draft-ietf-tsvwg-natsupp-05.txt Pages : 20 Date : 2013-02-25 Abstract: Stream Control Transmission Protocol [RFC4960] provides a reliable communications channel between two end-hosts in many ways similar to TCP [RFC0793]. With the widespread deployment of Network Address Translators (NAT), specialized code has been added to NAT for TCP that allows multiple hosts to reside behind a NAT and yet use only a single globally unique IPv4 address, even when two hosts (behind a NAT) choose the same port numbers for their connection. This additional code is sometimes classified as Network Address and Port Translation (NAPT). To date, specialized code for SCTP has not yet been added to most NATs so that only pure NAT is available. The end result of this is that only one SCTP capable host can be behind a NAT. This document describes the protocol extensions required for the SCTP endpoints to help NATs provide similar features of NAPT in the single-point and multi-point traversal scenario. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-natsupp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tsvwg-natsupp-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tsvwg-natsupp-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gorry@erg.abdn.ac.uk Tue Feb 26 01:29:52 2013 Return-Path: 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 E3B8521F8996 for ; Tue, 26 Feb 2013 01:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVT4cieeqrZe for ; Tue, 26 Feb 2013 01:29:52 -0800 (PST) Received: from spey.erg.abdn.ac.uk (spey.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 33D5A21F892D for ; Tue, 26 Feb 2013 01:29:52 -0800 (PST) Received: from www.erg.abdn.ac.uk (blake.erg.abdn.ac.uk [139.133.210.30]) by spey.erg.abdn.ac.uk (Postfix) with ESMTPSA id 0E8752B4275 for ; Tue, 26 Feb 2013 09:29:51 +0000 (GMT) Received: from 212.159.18.54 (SquirrelMail authenticated user gorry) by www.erg.abdn.ac.uk with HTTP; Tue, 26 Feb 2013 09:29:51 -0000 Message-ID: <9fcbbace44c814766a9e7c7050956ece.squirrel@www.erg.abdn.ac.uk> Date: Tue, 26 Feb 2013 09:29:51 -0000 From: gorry@erg.abdn.ac.uk To: tsvwg@ietf.org User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [tsvwg] TSVWG - Draft Agenda for Orlando IETF X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 09:29:53 -0000 Here is my first-cut at an Agenda: http://www.ietf.org/proceedings/86/agenda/agenda-86-tsvwg As ever, our time is valuable and some talks have still to be confirmed, so this is a draft only. Please send any comments (or omissions) to me. If at all possible I'd like to ensure there is some time to tell people about new -00 drafts, these are at the end of our agenda. I will issue a final agenda by the end of the week. Gorry (TSVWG Co-Chair) From brian.e.carpenter@gmail.com Tue Feb 26 06:45:54 2013 Return-Path: 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 6088921F8AC0 for ; Tue, 26 Feb 2013 06:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.905 X-Spam-Level: X-Spam-Status: No, score=-102.905 tagged_above=-999 required=5 tests=[AWL=0.694, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJvYUA1eW9An for ; Tue, 26 Feb 2013 06:45:54 -0800 (PST) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id A790A21F8ABC for ; Tue, 26 Feb 2013 06:45:53 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so3391924wgd.4 for ; Tue, 26 Feb 2013 06:45:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kPLTCrh0NM0Q7/UdWaYVWVTNqQ8UyvdsPbbweRR+KB4=; b=oRzoxgX44Ae1Fj4sOUkD5t+eqVA8lwV1/CMjaTDHUvs1aTI5BxLLpr1dpEWaBS8XLJ YbOKYrvblXux7AselmTLTE1V3UIIMh1gv+nlxMe6/f7zelIWQAsqD0MPUitKTmVEMivc bUtgsOeC1AJpXPqBFaYjkoPN3T/U6NfvfYjmv9fvwqZfKjtw3isf7Fqn0i60hw9nFmQO qCSZqdyphdy9QCpfcuX7SwDYSqRSPe/tj2cVffPYTQcAygHAUzxdWyaQYtakYVID7YNa 5Q6ailShqd1aEnHSHE0roQ4OvrpRUaDIgST8I9/OlShDvUlXdRn98KSgZFHZ7LAXDBnr /xug== X-Received: by 10.180.84.162 with SMTP id a2mr19653231wiz.14.1361889952648; Tue, 26 Feb 2013 06:45:52 -0800 (PST) Received: from [128.232.110.102] (c102.al.cl.cam.ac.uk. [128.232.110.102]) by mx.google.com with ESMTPS id gy2sm2410319wib.3.2013.02.26.06.45.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 06:45:51 -0800 (PST) Message-ID: <512CCAA4.5090605@gmail.com> Date: Tue, 26 Feb 2013 14:45:56 +0000 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tsvwg@ietf.org References: <20130225193552.18928.75153.idtracker@ietfa.amsl.com> In-Reply-To: <20130225193552.18928.75153.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [tsvwg] I-D Action: draft-polk-tsvwg-new-dscp-assignments-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:45:54 -0000 Hi, I don't really understand why this draft, and draft-polk-tsvwg-rfc4594-update, are so profligate with DSCP values. DSCP values are only bound to specific PHBs locally, with some recommended bindings as shown in the IANA registry. But if we have two similar-but-different PHBs, such that a given diffserv domain will only use one of them, it is perfectly fine to re-use a DSCP value. For example, is CS5-Admit (as defined in draft-polk-tsvwg-rfc4594-update) ever going to be used in the same domain as CS5 (RFC2474)? If not, there is no need to allocate a new recommended code-point. There might be a need to allocate a PHB ID for signaling or SLAs, but that is not a precious resource (RFC3140). > The key part of the above quote is > > "... which should be preferentially utilized for standardized > assignments if Pool 1 is ever exhausted..." > > which we here take to mean 'SHOULD NOT use unless you have a really > good reason to use'. I don't see what's hard to interpret about "if Pool 1 is ever exhausted". As far as I can tell, it isn't, so Pool 3 isn't yet available. > One reason for assigning out of Pool 3 is to get similar > marking from layer 2 technologies that only have 3 bits to use for > their value, not 6 bits. That doesn't convince me. Clearly you have to map at the boundary of one of those techologies, but a 6 bit to 3 bit map is not a big deal, and you can't reasonably expect to get away with just masking off 3 bits in the general case. Incidentally, I don't think that -rfc4594-update yet does all that is called for by Section 5 of RFC3086 in defining the new PHBs. Brian From lars@netapp.com Wed Feb 27 10:35:13 2013 Return-Path: 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 BD8BE21F89B2 for ; Wed, 27 Feb 2013 10:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.36 X-Spam-Level: X-Spam-Status: No, score=-9.36 tagged_above=-999 required=5 tests=[AWL=-0.763, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, SARE_HEXOCTDWORD=2, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScNPJkdvPdyP for ; Wed, 27 Feb 2013 10:35:12 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0D62621F8970 for ; Wed, 27 Feb 2013 10:35:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,749,1355126400"; d="scan'208";a="12429162" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 27 Feb 2013 10:35:11 -0800 Received: from vmwexceht02-prd.hq.netapp.com (vmwexceht02-prd.hq.netapp.com [10.106.76.240]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1RIZ8JZ026165; Wed, 27 Feb 2013 10:35:11 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.02.0328.009; Wed, 27 Feb 2013 10:35:08 -0800 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-01.txt Thread-Index: AQHOE3q64zZ/lynk9Um/G2gwsounUpiLV3eAgAM6BIA= Date: Wed, 27 Feb 2013 18:35:08 +0000 Message-ID: References: <20130225170557.25596.27309.idtracker@ietfa.amsl.com> <512B9CF1.8030404@isi.edu> In-Reply-To: <512B9CF1.8030404@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-port-use-01.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:35:13 -0000 Hi, I gave this a quick read; here are some comments. Lars High-level: Somewhere in this document, we should point out strongly that service names are available FCFS w/o IANA assignment, and are therefore MUCH easier to use when a service needs to be rolled out quickly. Section 4., paragraph 4: > 0-1023 0x03FF Well-Known (a.k.a. 'system') > 1024-49151 0x0300-0xBFFF Registered (a.k.a. 'user') > 49152-65535 0xC000-0xFFFF Dynamic/Private 1024 is 0x400 Section 5., paragraph 6: > http:51509//www.example.com/ Actually, it would be http://www.example.com:51509/ Section 7.2., paragraph 0: > 7.2. How Many Ports? You might want to add in this section that in the past, when the port number space was less crowded, multiple ports were assigned for one service, e.g., X11. However, that does not reflect current practice anymore, and the existence of such assignments in the IANA table does not constitute a precedent. Section 7.3., paragraph 5: > >> Developers SHOULD NOT apply for system ports because the > increased privilege they provide is not always enforced. Developers CANNOT simply apply for system ports since RFC6335 was published. It very clearly says that the policy is "IETF Review" or "IESG Approval" only, and that a "...request for a System Port number MUST document *both* why using a port number from the Dynamic Ports range is unsuitable *and* why using a port number from the User Ports range is unsuitable for that application. Section 7.3., paragraph 7: > At some future date, it might be useful to deprecate the distinction > between system and user ports altogether, but merely avoiding system > ports would potentially waste only approximately 180 of 1024 values > (17%). You might want to add somewhere in this section that many services that need to bind to a system port go through great lengths in order to drop root privileges as soon as they have bound, in order to reduce their attack surface. So it's actually MORE secure to run on a port > 1023. Section 7.6., paragraph 7: > >> UDP multi-host services SHOULD use multicast rather than > broadcast. This suggestion isn't really about port use, and therefore maybe not in scope of this document. Section 7.6., paragraph 8: > Designers should be very careful in creating services over > transports that do not support congestion control or error recovery, > notably UDP. There are several issues that should be considered in > such cases: Ditto. As much as I'd like a "how to design an application protocol" BCP, this one isn't it. Much of the UDP-specific stuff is also already discussed in more detail in RFC5405. Section 7.7., paragraph 4: > Deployments that use ports before deployment complicate IANA > management of the port space. Keep in mind that this recommendation > protects both other parties and you; it helps ensure that your > desired number and service name are available when assigned. The > list of currently unassigned numbers is just that - *currently* > unassigned. It does not reflect pending applications, nor > applications that might arrive before yours. Waiting for an official > IANA assignment reduces the chance that your assignment will > conflict with another deployed service. You might want to say something about how long an IANA allocation typically takes to process. From sebastien.jobert@orange.com Thu Feb 28 05:13:19 2013 Return-Path: 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 0ADED21F8AC3 for ; Thu, 28 Feb 2013 05:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mm4o7PXm55uk for ; Thu, 28 Feb 2013 05:13:18 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E7B2721F8996 for ; Thu, 28 Feb 2013 05:13:17 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 16D593244ED; Thu, 28 Feb 2013 14:13:17 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id EF45F27C053; Thu, 28 Feb 2013 14:13:16 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 28 Feb 2013 14:13:16 +0100 From: To: "Ruediger.Geib@telekom.de" , "tsvwg@ietf.org" Thread-Topic: New version notification draft-geib-tsvwg-diffserv-intercon-02.txt Thread-Index: Ac4TSjIrWVcoB5h5Q2+YBmDr3UIOBgACJ1JwAJhuw0A= Date: Thu, 28 Feb 2013 13:13:16 +0000 Message-ID: <526_1362057197_512F57EC_526_12045_1_7F67B91079F7C74F9DAB55FC7872661E0B0400@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.2.28.105416 Subject: Re: [tsvwg] New version notification draft-geib-tsvwg-diffserv-intercon-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 13:13:19 -0000 Hi,=20 First of all, I appreciate this work, especially as it clearly points out t= hat only a limited number of classes is deployed in the core networks in pr= actice (similarly to RFC5127). I reviewed the latest version of this draft, and I spent some time also hav= ing a look to Y.1566. Please find below some of my comments. - Page 6, you mention 4 classes (Class Priority, Bulk inelastic, Assured, D= efault) with a reference to Y.1566. However, in Y.1566, the 4 classes corre= sponding to "Ordinary Packet Service QoS Classes" are not the same (e.g. Cr= itical / network management class is missing in your IETF draft), and it se= ems that you actually mixed classes mentioned as "auxiliary Packet Service = QoS Classes" in Y.1566 (e.g. Bulk inelastic belongs to this second set in Y= .1566). Is there a reason for this? Should the two documents be aligned? - Page 7, you say that: "At interconnection points, the following PHBs shou= ld be accepted between interconnected parties:" Does it imply that it is ex= pected that all the operators implement exactly these PHBs in their network= in each node? It seems quite difficult for me to mandate that all the netw= orks behave the same way, since various network operators have in general d= ifferent configurations/policies. I thought that the original proposal was = simply to define a set of codepoints for interconnection points, but leave = the actual network behavior as operator-specific (which is quite reasonable= ). Did I misunderstand something? - You mention the term "conditioning" at several places in your draft; coul= d you define precisely what is meant by this? For instance, is it referring= to the properties of one particular class of service? Else? - About MPLS TC or Ethernet P-Bits and IP precedence, I'll tend to think th= at referencing the old IP precedence mechanism may not be the most effectiv= e way to explain what is suggested (and done in practice) - you might perha= ps simply mention that the first 3 bits of the DSCP are used, it might be c= learer. I would personally suggest not talking about IP precedence at all. Finally, I wonder if a possible revision of RFC5127 might include most of t= he aspects discussed in this draft. Indeed, the classes (treatment aggregat= es) described in RFC5127 should ideally be aligned with this draft. Also, c= urrent RFC5127 contains a section 5 called "Treatment Aggregates and Inter-= Provider Relationships". This could potentially be a place where to put som= e of the considerations on interconnection points. I won't be in Orlando, but I'll try to follow remotely these discussions. Thanks. BR, S=E9bastien -----Message d'origine----- De=A0: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] De la part de= Ruediger.Geib@telekom.de Envoy=E9=A0: lundi 25 f=E9vrier 2013 13:42 =C0=A0: tsvwg@ietf.org Objet=A0: [tsvwg] New version notification draft-geib-tsvwg-diffserv-interc= on-02.txt Hello, below you'll find the links to a revised version of the DiffServ intreconnection scheme. I forgot some references in version -01, so I added a version -02 before cutoff. To simplify comparing it with -00, here's a diff -00 vs. -02: http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-geib-ts= vwg-diffserv-intercon-00.txt&url2=3Dhttp://tools.ietf.org/id/draft-geib-tsv= wg-diffserv-intercon-02.txt Regards, Ruediger -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, February 25, 2013 12:20 PM To: Geib, R=FCdiger Subject: New Version Notification for draft-geib-tsvwg-diffserv-intercon-02= .txt A new version of I-D, draft-geib-tsvwg-diffserv-intercon-02.txt has been successfully submitted by Ruediger Geib and posted to the IETF repository. Filename: draft-geib-tsvwg-diffserv-intercon Revision: 02 Title: DiffServ interconnection classes and practice Creation date: 2013-02-25 Group: Individual Submission Number of pages: 12 URL: http://www.ietf.org/internet-drafts/draft-geib-tsvwg-diffs= erv-intercon-02.txt Status: http://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-= intercon Htmlized: http://tools.ietf.org/html/draft-geib-tsvwg-diffserv-inter= con-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-geib-tsvwg-diffse= rv-intercon-02 Abstract: This document proposes a limited set of interconnection QoS PHBs and PHB groups. It further introduces some DiffServ deployment aspects. The proposals made here should be integrated into a revised version of RFC5127. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Ruediger.Geib@telekom.de Thu Feb 28 05:31:31 2013 Return-Path: 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 80D6921F880F for ; Thu, 28 Feb 2013 05:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cerqACcPFzN8 for ; Thu, 28 Feb 2013 05:31:31 -0800 (PST) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 69E2421F8745 for ; Thu, 28 Feb 2013 05:31:29 -0800 (PST) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 28 Feb 2013 14:31:26 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 28 Feb 2013 14:31:25 +0100 From: To: Date: Thu, 28 Feb 2013 14:31:24 +0100 Thread-Topic: New version notification draft-geib-tsvwg-diffserv-intercon-02.txt Thread-Index: Ac4TSjIrWVcoB5h5Q2+YBmDr3UIOBgACJ1JwAAOdHYAAlLh6wA== Message-ID: References: <94C682931C08B048B7A8645303FDC9F36EB3C82FE5@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EB3C82FE5@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: pierre.levis@orange.com, tsvwg@ietf.org, christian.jacquenet@orange.com Subject: Re: [tsvwg] New version notification draft-geib-tsvwg-diffserv-intercon-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 13:31:31 -0000 Dear Med thanks for your comments. I mark your comments and my replies below as foll= ows: [MB] Mohamed Boucadair [RG] Ruediger Geib Regards, Ruediger -------- [MB] The document mentions SLA without citing a reference. FWIW, you can cite http://tools.ietf.org/html/draft-boucadair-connect= ivity-provisioning-profile-02. That document defines various performance guarantees clauses to be included in a connectivity agreement (can be used between two network providers). [RG] That would be an example of an SLA. Yes, such a reference could be added in -03. [MB] You may add the following text to the introduction: The current practices in operational network is to reset DSCP to 0 in interconnection points. An ASBR does not trust the marking set b= y an external adjacent ASBR. This practice is likely to evolve if interconnection agreements are reviewed to include QoS performance guarantees. Those agreements may include in particular the marking policy to be enforced in the interconnection link. [RG] Such a statement could be added. Apart from the trust issue, there are others: a carrier doesn't know the class corresponding to a received DSCP. Further, a carrier will protect the own QoS classes from interference of uncontrolled external traffic, [MB] I fully agree having a well defined set of classes will ease QoS interconnection practices (e.g., how to bound my classes to those of an adjacent domain). Nevertheless, having standard codepoints assigned to those QoS classes may be of less interest if we assume these values are agreed between adjacent provided and are captured in an interconnection agreement. The text should motivate further such need. You may add the following for instance: Having a limited set of codepoints for QoS interconnect are likely t= o accelerate network provisioning by providing generic policies to be enforced at the interconnection nodes. The use of standard code poi= nts ease automation of network interconnection agreement and settlement procedures. [RG] Thanks, understood and I agree. I will add your text or similar one to= the arguments already given in version -03. [MB] You may also add the following: Network providers may agree to use other codepoints than those defined in this document. This document does not require network providers to expose their internal QoS configuration (e.g., number Qo= S classes, internal DSCP codepoints, classification policies, etc.). [RG] Thanks, I had the former in mind already. It's one reason why there sh= ould be some codepoint reserve left. Will be added too in -03. Cheers, Med From acmorton@att.com Thu Feb 28 06:25:05 2013 Return-Path: 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 80F7E21F84D9 for ; Thu, 28 Feb 2013 06:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.201 X-Spam-Level: X-Spam-Status: No, score=-106.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0U2Ani70WBE for ; Thu, 28 Feb 2013 06:25:03 -0800 (PST) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 2852521F845A for ; Thu, 28 Feb 2013 06:24:57 -0800 (PST) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 49F7D120711; Thu, 28 Feb 2013 09:27:31 -0500 (EST) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 80EF5E36F4; Thu, 28 Feb 2013 09:18:14 -0500 (EST) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Thu, 28 Feb 2013 09:24:56 -0500 From: "MORTON JR., ALFRED (AL)" To: "TSBSG12, ITU (tsbsg12@itu.int)" Date: Thu, 28 Feb 2013 09:24:55 -0500 Thread-Topic: New Liaison Statement, "In response to: Development of Informative Codepoint mapping in ITU-T Study Group 12" Thread-Index: Ac4VvpJvPDcE2mvTSQWN5aIkTHgiQgAACwkw Message-ID: References: <20130228141853.13084.80607.idtracker@ietfa.amsl.com> In-Reply-To: <20130228141853.13084.80607.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Gorry Fairhurst , Transport Area Working Group Discussion List , James Polk Subject: Re: [tsvwg] New Liaison Statement, "In response to: Development of Informative Codepoint mapping in ITU-T Study Group 12" X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 14:25:05 -0000 VGhhbmtzIERhdmlkLCBhZGRpbmcgdGhlIFNHIDEyIFNlY3JldGFyaWF0IENvbnRhY3QgYWRkcmVz cywNCnNvIHRoaXMgcmVwbHkgY2FuIGJlIHBvc3RlZCBpbiBvdXIgZG9jdW1lbnQgc3lzdGVtLg0K DQpyZWdhcmRzLA0KQWwNCihhcyBBY3RpbmcgUmFwcG9ydGV1ciwgUXVlc3Rpb24xNy8xMjoNClJh cHBvcnRldXIgYXNzaWdubWVudHMgZm9yIHRoZSAyMDEzLTIwMTYgDQpTdHVkeSBQZXJpb2QgYXJl IHVub2ZmaWNpYWwgdW50aWwNCmFzc2lnbmVkIGF0IHRoZSBvcGVuaW5nIHBsZW5hcnkuKQ0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExpYWlzb24gU3RhdGVtZW50IE1h bmFnZW1lbnQgVG9vbCBbbWFpbHRvOmxzbXRAaWV0Zi5vcmddDQo+IFNlbnQ6IFRodXJzZGF5LCBG ZWJydWFyeSAyOCwgMjAxMyA5OjE5IEFNDQo+IFRvOiBNT1JUT04gSlIuLCBBTEZSRUQgKEFMKQ0K PiBDYzogR29ycnkgRmFpcmh1cnN0OyBKYW1lcyBQb2xrOyBXZXNsZXkgRWRkeTsgTWFydGluIFN0 aWVtZXJsaW5nOyBFbGlvdA0KPiBMZWFyOyBUcmFuc3BvcnQgQXJlYSBXb3JraW5nIEdyb3VwIERp c2N1c3Npb24gTGlzdDsgRGF2aWQgQmxhY2s7IERhdmlkDQo+IEJsYWNrDQo+IFN1YmplY3Q6IE5l dyBMaWFpc29uIFN0YXRlbWVudCwgIkluIHJlc3BvbnNlIHRvOiBEZXZlbG9wbWVudCBvZg0KPiBJ bmZvcm1hdGl2ZSBDb2RlcG9pbnQgbWFwcGluZyBpbiBJVFUtVCBTdHVkeSBHcm91cCAxMiINCj4g DQo+IFRpdGxlOiBJbiByZXNwb25zZSB0bzogRGV2ZWxvcG1lbnQgb2YgSW5mb3JtYXRpdmUgQ29k ZXBvaW50IG1hcHBpbmcgaW4NCj4gSVRVLVQgU3R1ZHkgR3JvdXAgMTINCj4gU3VibWlzc2lvbiBE YXRlOiAyMDEzLTAyLTI4DQo+IFVSTCBvZiB0aGUgSUVURiBXZWIgcGFnZTogaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTI0MS8NCj4gDQo+IEZyb206IFRyYW5zcG9ydCBBcmVh IFdvcmtpbmcgR3JvdXAgKERhdmlkIEJsYWNrIDxEYXZpZCBCbGFjaw0KPiA8ZGF2aWQuYmxhY2tA ZW1jLmNvbT4+KQ0KPiBUbzogSVRVLVQgU0cgMTIgKEEuIEMuIE1vcnRvbiA8YWNtb3J0b25AYXR0 LmNvbT4pDQo+IENjOiBHb3JyeSBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPixKYW1l cyBQb2xrDQo+IDxqbXBvbGtAY2lzY28uY29tPixXZXNsZXkgRWRkeSA8d2VzQG10aS1zeXN0ZW1z LmNvbT4sTWFydGluIFN0aWVtZXJsaW5nDQo+IDxtYXJ0aW4uc3RpZW1lcmxpbmdAbmVjbGFiLmV1 PixFbGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbT4sVHJhbnNwb3J0IEFyZWENCj4gV29ya2luZyBH cm91cCBEaXNjdXNzaW9uIExpc3QgPHRzdndnQGlldGYub3JnPg0KPiBSZXBvbnNlIENvbnRhY3Q6 IERhdmlkIEJsYWNrIDxkYXZpZC5ibGFja0BlbWMuY29tPg0KPiBUZWNobmljYWwgQ29udGFjdDog RGF2aWQgQmxhY2sgPGRhdmlkLmJsYWNrQGVtYy5jb20+DQo+IFB1cnBvc2U6IEluIHJlc3BvbnNl DQo+IFJlZmVyZW5jZWQgbGlhaXNvbjogRGV2ZWxvcG1lbnQgb2YgSW5mb3JtYXRpdmUgQ29kZXBv aW50IG1hcHBpbmcgaW4gSVRVLVQNCj4gU3R1ZHkgR3JvdXAgMTIgKGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9saWFpc29uLzExNjUvKQ0KPiBCb2R5OiBUaGUgVHJhbnNwb3J0IEFyZWEgV29y a2luZyBHcm91cCB0aGFua3MgSVRVLVQncyBzdHVkeSBncm91cCAxMiBmb3INCj4gaXRzIGxpYWlz b24gb2YgMyBKdWx5IDIwMTIuICBXZSBub3RlIHdpdGggYXBwcmVjaWF0aW9uIHRoZSBhY3RpdmUN Cj4gaW52b2x2ZW1lbnQgb2YgTXNzcnMuIEdlaWIgYW5kIE1vcnRvbi4NCj4gDQo+IFNpbmNlIGl0 cyByZWNlaXB0IHdlIGhhdmUgaGFkIHNldmVyYWwgdmVyeSBlbmdhZ2luZyBkaXNjdXNzaW9ucywg Ym90aCBpbg0KPiBwZXJzb24sIGFuZCBvbiBvdXIgbWFpbGluZyBsaXN0IHRoYXQgaGF2ZSBjb25z aWRlcmVkIHRoZSBhcHBlbmRpY2VzIHRvDQo+IFkuUW9TbWFwIChub3cgWS4xNTY2KS4gIFRoZSBX RyBoYXMgY29uY2x1ZGVkIHRoYXQgd2Ugd2lsbCB0YWtlIG9uIGludGVyLQ0KPiBwcm92aWRlciBR b1MgYXMgYSB3b3JrIGl0ZW0uIFRoaXMgaXMgYSBmaXJzdCBzdGVwLiAgVGhlIFdHIGFudGljaXBh dGVzDQo+IGNvbnRyaWJ1dGlvbnMgYWxvbmcgdGhlc2UgbGluZXMgdG8gY29uc2lkZXIuICBXZSB3 aWxsIGtlZXAgeW91IGFwcHJpc2VkIG9mDQo+IHdvcmsgaW4gdGhpcyBhcmVhLg0KPiBBdHRhY2ht ZW50czoNCj4gDQo+IE5vIGRvY3VtZW50IGhhcyBiZWVuIGF0dGFjaGVkDQoNCg== From Ruediger.Geib@telekom.de Thu Feb 28 07:47:04 2013 Return-Path: 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 DF67021F8A7B for ; Thu, 28 Feb 2013 07:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji1hMx91MtCK for ; Thu, 28 Feb 2013 07:47:03 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [80.149.113.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7A26D21F8B6E for ; Thu, 28 Feb 2013 07:47:02 -0800 (PST) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail21.telekom.de with ESMTP/TLS/AES128-SHA; 28 Feb 2013 16:46:56 +0100 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 28 Feb 2013 16:46:49 +0100 From: To: Date: Thu, 28 Feb 2013 16:46:48 +0100 Thread-Topic: New version notification draft-geib-tsvwg-diffserv-intercon-02.txt Thread-Index: Ac4TSjIrWVcoB5h5Q2+YBmDr3UIOBgACJ1JwAJhuw0AAA3+sUA== Message-ID: References: <526_1362057197_512F57EC_526_12045_1_7F67B91079F7C74F9DAB55FC7872661E0B0400@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <526_1362057197_512F57EC_526_12045_1_7F67B91079F7C74F9DAB55FC7872661E0B0400@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: tsvwg@ietf.org Subject: Re: [tsvwg] New version notification draft-geib-tsvwg-diffserv-intercon-02.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 15:47:04 -0000 Hello Sebastien, thanks for your comments. Your statements and my replies are marked as foll= ows below: [SJ] Sebastien Jobert [RG] R=FCdiger Geib Regards, R=FCdiger ---------- [SJ] Page 6, you mention 4 classes (Class Priority, Bulk inelastic, As= sured, Default) with a reference to Y.1566. However, in Y.1566, the 4 classes correspo= nding to "Ordinary Packet Service QoS Classes" are not the same (e.g. Critical = / network management class is missing in your IETF draft), and it seems that you actually m= ixed classes mentioned as "auxiliary Packet Service QoS Classes" in Y.1566 (e.g. Bu= lk inelastic belongs to this second set in Y.1566). Is there a reason for this? Sho= uld the two documents be aligned? [RG] DiffServ-Intercon and Y.1566 should be aligned (and I'd add GSMA IR.34= and MEF 23.1). ITU reached agreement on those classes all carriers support ("ordinary") an= d some which see some support ("auxiliary"). ITU worked with full consensus here, not wi= th rough consensus. That's why I included class Bulk Inealstic in the IETF work more= prominently (but look for section 6 of Y.1566, it is proposed there too). ITU class cri= tcal (network management) is mentioned in the DiffServ-Intercon introduction:...An example for an int= ernal PHB may be CS6... I'm happy to expand on that, given there's support. [SJ] Page 7, you say that: "At interconnection points, the following P= HBs should be accepted between interconnected parties:" Does it imply that it is exp= ected that all the operators implement exactly these PHBs in their network in each no= de? It seems quite difficult for me to mandate that all the networks behave the sam= e way, since various network operators have in general different configurations/pol= icies. I thought that the original proposal was simply to define a set of codepoints fo= r interconnection points, but leave the actual network behavior as operator-specific (wh= ich is quite reasonable). Did I misunderstand something? [RG] Good point, I may be unclear here. I'd expect the classes to be suppor= ted. Class definitions should stay qualitative. Class properties should be standardise= d. The PHBs should be maintained in the sense that if received with different codepoint= s at interconnection, they should leave with different codepoints on interconnec= tion. So treating different PHBs of one class only as one class is allright. The minimum expectation then is support of a class a specified, if the Inte= rcon class and codepoint scheme is used. I don't think there should be an obligation t= o support all four classes that's a SHOULD at best. I guess the draft needs to say th= at. [SJ] You mention the term "conditioning" at several places in your dra= ft; could you define precisely what is meant by this? For instance, is it referr= ing to the properties of one particular class of service? Else? [RG] Good point and I obviously need to expand terminology. By conditioning= I meant scheduling & Active Queue Management (if any). And here "conditioning" does= n't apply - that has been a late change and an ill formulated one. Sorry for causing confusion. In fact, what's needed is something "QoS forwarding". I'm open for better s= uggestions. [SJ] About MPLS TC or Ethernet P-Bits and IP precedence, I'll tend to = think that referencing the old IP precedence mechanism may not be the most effect= ive way to explain what is suggested (and done in practice) - you might perhaps s= imply mention that the first 3 bits of the DSCP are used, it might be cleare= r. I would personally suggest not talking about IP precedence at all. [RG] Good idea. If the WG reaches conensus that the first 3 bits of the DSC= Ps are used to the purpose I specify (and in fact: specification follows implementation= here) I'm happy to rewrite the draft without refering to IP-precedence. I'll add = that to the presentation. [SJ] Finally, I wonder if a possible revision of RFC5127 might include= most of the aspects discussed in this draft. Indeed, the classes (treatment ag= gregates) described in RFC5127 should ideally be aligned with this draft. Also, = current RFC5127 contains a section 5 called "Treatment Aggregates and Inter-Pr= ovider Relationships". This could potentially be a place where to put some of= the considerations on interconnection points. [RG] Basically you are right. But to me RFC5127 requires a rewrite also wit= hout the contents of DiffServ-Intercon. I'd be very unhappy if consensus was reached= on DiffServ-Intercon but the all is delayed because there's no consensus on a RFC5127 rewrite. I'm open for a discussion however. From david.black@emc.com Thu Feb 28 15:09:23 2013 Return-Path: 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 E779521F8A4F for ; Thu, 28 Feb 2013 15:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCE62nAzBkbx for ; Thu, 28 Feb 2013 15:09:23 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 167EB21F884B for ; Thu, 28 Feb 2013 15:09:22 -0800 (PST) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1SN9Mr7031437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 28 Feb 2013 18:09:22 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Thu, 28 Feb 2013 18:09:11 -0500 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.222.70.203]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r1SN9BfN007623 for ; Thu, 28 Feb 2013 18:09:11 -0500 Received: from mx15a.corp.emc.com ([169.254.1.74]) by mxhub06.corp.emc.com ([128.222.70.203]) with mapi; Thu, 28 Feb 2013 18:09:10 -0500 From: "Black, David" To: "tsvwg@ietf.org" Date: Thu, 28 Feb 2013 18:09:09 -0500 Thread-Topic: David Black's comments on draft-geib-tsvwg-diffserv-intercon- Thread-Index: Ac4WCJ1gu0g8jPPJSvG1oWa000MbIg== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7128F9F7414@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [tsvwg] David Black's comments on draft-geib-tsvwg-diffserv-intercon- X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 23:09:24 -0000 These comments are as an individual - In general, this is a valuable contribution, including the specific proposal of the 4 diffserv interconnect classes. It may be a good idea to add a mapping from the current RFC 4594 classes into these classes as a complement to the current PHB-oriented material. Abstract and Introduction: A possible tsvwg direction forward is to revise RFC 5127 to focus on network internals and produce a separate RFC fo= r interconnection of network edges - that separation is consistent with the discussion in Section 3 of this draft about mapping between internal and interconnection schemes. That distinction between schemes is crucial, IMHO - it's in the second paragraph of this draft's introduction, but could use some more emphasis. OTOH, I'd remove the text that focuses this draft on revising RFC 5127, as that may not be the most effective path forward, although it'd probably be ok to retain some of the language in the introduction about concepts in this draft being relevant to a revision of RFC 5127. The introduction should explain more about copying of the "IP Precedence Bi= ts" to the MPLS TC or Ethernet P-Bits - the crucial thing that needs to be stat= ed is that the bits involved are the first 3 bits in the DSCP, and the values for the recommended DSCPs for AF and EF were chosen in part based on this consideration, so that EF has a higher priority than AF (and most other traffic) when this is done. This is described in Section 5, but should also be explained in the introduction.=20 The last paragraph on p.3 indicates that internal PHBs and codepoints may be added later - I don't think that would be a good idea. Rather, it'd be better (IMHO) to focus this draft on the interconnect problem to keep it cleanly separated from the RFC 4594 update discussion that also affects RFC= 5127. That paragraph could also use some minor rephrasing to avoid any implicatio= n that this draft has priority on use of MPLS TC space - talking about other uses as peer users of that space would be better than the current "leave so= me MPLS TC codespace" language. It's recently been discovered that draft-ietf-idr-sla-exchange-00.txt is related to this work, so that draft should be mentioned. The idr-sla-exchange draft is rather descriptive, in contrast to this diffserv interconnect draft being prescriptive. The middle bullet in the list at the end of section 3 isn't quite right. There are only 8 codepoints available for DSCP encoding in MPLS and Etherne= t, but some PHBs (e.g., AF) can consume more than one codepoint. The last bul= let at the end of section 3 is unclear on whether this is about DSCPs, MPLS (an= d Ethernet) codepoints, or both. The first 3 paragraphs of section 4 feel like they belong in a related work section, possibly an appendix, which would also be a good place for a longe= r discussion of Y.1566, which is the basis for a lot of this material. I'm not sure I understand the point of Section 6, and would suggest removin= g it. I would also combine sections 5 and 7 into a single section. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Thu Feb 28 18:03:23 2013 Return-Path: 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 D8BB621F858A; Thu, 28 Feb 2013 18:03:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gW3RzWfUd7lX; Thu, 28 Feb 2013 18:03:22 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 733E221F857E; Thu, 28 Feb 2013 18:03:22 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r2123Kg3019272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Feb 2013 21:03:20 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 28 Feb 2013 21:03:06 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r21236Lu006056; Thu, 28 Feb 2013 21:03:06 -0500 Received: from mx15a.corp.emc.com ([169.254.1.74]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Thu, 28 Feb 2013 21:03:05 -0500 From: "Black, David" To: "Shitanshu Shah (svshah)" Date: Thu, 28 Feb 2013 21:03:04 -0500 Thread-Topic: I-D Action: draft-ietf-idr-sla-exchange-00.txt Thread-Index: AQHOFQxM0cBFOjlbZk+SD9PaSGdNOZiOQWGAgAGuRKA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE7128F9F7443@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE7128F9F7114@MX15A.corp.emc.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "idr@ietf.org" , "tsvwg@ietf.org" Subject: Re: [tsvwg] I-D Action: draft-ietf-idr-sla-exchange-00.txt X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2013 02:03:24 -0000 (+tsvwg list) For context this is about the relationship of draft-ietf-idr-sla-exchange-0= 0 and draft-geib-tsvwg-diffserv-intercon-02. Both are currently on the tsvwg WG agenda for Monday afternoon in Orlando (idr conflicts w/tsvarea on Wed, so the idr session won't work well for looking at both drafts). The purpos= e of this note is to start some discussion in preparation for that session. This message is sent as an individual with . The drafts appear to be aimed at different, but overlapping use cases - the idr-sla-exchange draft appears to be primarily concerned with provider-customer relationships and purchased destination (AS) specific service (e.g., see Section 7). The diffserv-intercon draft is primarily concerned with interconnection of carrier networks - while that's primarily a provider-provider case that appears to be of less interest to the idr-sla-exchange draft, both the provider-customer and purchased service (e.g., in the form of transit) cases may occur in provider-provider relationships. As already noted in the thread, the drafts support rather different SLA frameworks among networks: - idr-sla-exchange is descriptive and broad - it anticipates a plethora of possible multi-class SLA specifications that may need to be described based on specific contracts with customers and other network operators. It includes bandwidth thresholds and remarking instructions for a variety of marking mechanisms (e.g., diffserv,=09 Ethernet priority). - diffserv-intercon prescribes a single multi-class SLA specification and a single set of diffserv PHBs (which have preferred DSCPs) intended for widespread use by a single carrier. Based on the above, the drafts could well be complementary, although more discussion of the relationship among them seems like a good idea in Orlando= . In addition, I concur with Brian's conclusion on the idr-sla-exchange draft= : > >> I think this draft needs to be discussed in TSVWG before it goes > >> much further. A consistent model for QoS metric signaling is needed > >> before we standardize a mapping onto IDR. In particular the various rates in that idr-sla-exchange draft appear to be inventing a new rate-based QoS specification framework, and the draft isn't particularly precise job of specifying it (as Brian's comments point out). This sort of work is not new to IETF, e.g., see the FLOWSPEC concept in RFC 2210, and the QSPEC concept in RFC 5975, which reuses the basic=20 FLOWSPEC concept in a completely different protocol framework. Thanks, --David > -----Original Message----- > From: Shitanshu Shah (svshah) [mailto:svshah@cisco.com] > Sent: Wednesday, February 27, 2013 7:00 PM > To: Black, David; Brian E Carpenter; draft-ietf-idr-sla- > exchange.all@tools.ietf.org > Cc: tsvwg-chairs@ietf.org; idr@ietf.org > Subject: Re: I-D Action: draft-ietf-idr-sla-exchange-00.txt > Importance: High >=20 >=20 > Hi David, >=20 > In the context of this discussion, couple of important points of > motivation/consideration for sla-exchange draft >=20 > - It is critical to have Diffserv support in SLA exchange. However, at th= e > same time, it should not be limited to Diffserv only. The SLA exchange > language in draft-ietf-idr-sla-exchange-00.txt should work for other type= s > of classification rules as well >=20 > - Current stat of SLA exchange draft does not intend to standardize any > code-point or PHB. Rather defined language in the draft merely refers > standards defined outside the context. You have precisely captured in you= r > comments that > SLA exchange draft is more descriptive in contrast to diffserv-intercon > which is more prescriptive >=20 > An additional note, SLA exchange may be among nodes in the same > administrative domain or across. To support earlier use-case, draft shoul= d > not have to mandate traffic class definition exchanged be based on > specific standards only. >=20 >=20 > Unfortunately, I will not be able to make it to IETF this time. However, = I > know Keyur (co-author) will be there and possibly other co-authors of the > draft. It surely will be good to have a conversation among key people and > as per outcome, we can have a further follow-up? >=20 > Regards, > Shitanshu >=20 >=20 >=20 > On 2/27/13 9:01 AM, "Black, David" wrote: >=20 > >With my tsvwg WG co-chair hat on, I strongly concur with Brian that this > >idr-sla-exchange draft needs to be discussed in the tsvwg WG. In Orland= o, > >the tsvwg WG meeting expects to take up: > > > > draft-geib-tsvwg-diffserv-intercon-02.txt > > https://datatracker.ietf.org/doc/draft-geib-tsvwg-diffserv-intercon/ > > > >which is considerably more prescriptive, in contrast to the > >idr-sla-exchange draft's descriptive approach. > > > >While that diffserv-intercon draft is not a WG draft, the tsvwg WG does > >intend to do work in this area, so some coordination to have a single > >overall approach seems advisable. This does *not* imply a priori that > >we need to select one draft and drop the other, and I surely do not want > >to work on BGP details in tsvwg ;-). > > > >Unfortunately the idr and tsvarea (Transport Area open meeting) sessions > >conflict on Wednesday morning in Orlando - would it make sense to take a= n > >initial look at this idr-sla-exchange draft during the Monday afternoon > >tsvwg session where there are conflicts with any routing WG meeting, and > >perhaps have key people talk privately afterwards ? > > > >Thanks, > >--David (tsvwg WG co-chair) > >---------------------------------------------------- > >David L. Black, Distinguished Engineer > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > >david.black@emc.com Mobile: +1 (978) 394-7754 > >---------------------------------------------------- > > > >> -----Original Message----- > >> From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > >> Sent: Monday, January 07, 2013 10:25 AM > >> To: draft-ietf-idr-sla-exchange.all@tools.ietf.org > >> Cc: tsvwg-chairs@ietf.org; idr@ietf.org > >> Subject: Re: I-D Action: draft-ietf-idr-sla-exchange-00.txt > >> > >> Hi, > >> > >> I don't understand which reference model for inter-domain SLAs > >> is being used here. There is an arbitrary list of element types > >> (IP_DSCP, MPLS_TC, 802_1Q_COS, 802_1Q_DEI, PHB_ID) and then > >> an arbitrary list of some QoS metrics. Presumably some of those > >> metrics map on to some of the element types, but it isn't obvious > >> and I am certain there are gaps. > >> > >> I don't think you can answer this with the text at the end of > >> Section 6: > >> > >> > There are well-defined recommendations that exist for traffic clas= s > >> > mapping between two technologies. Receiver MAY use those defined > >> > recommendations for traffic class mapping or MAY define its own as > >> > per its network Traffic Class service definition to map to > >>advertised > >> > Traffic Classes. It is completely up to the receiver how to defin= e > >> > such traffic class mapping. > >> > >> Firstly, if there are such recommendations, they should be given as > >> references. Secondly, why was the arbitrary set of QoS metrics chosen > >> and how do we know that they are necessary and sufficient? (For > >> example, I don't see any metric for drop rate, and for some traffic > >> classes that is an important metric.) > >> > >> I think this draft needs to be discussed in TSVWG before it goes > >> much further. A consistent model for QoS metric signalling is needed > >> before we standardise a mapping onto IDR. > >> > >> Nits > >> ---- > >> > >> [RFC2474], [RFC2475] and [RFC3140] are listed as references > >> (presumably for IP_DSCP and PHB_ID) but they are not cited in the > >> text. That will not get through the final ID-nits check. > >> > >> Also [RFC2475] is listed as a Normative reference, but it should > >> be Informative. > >> > >> Why is [RFC3552] listed as a reference? > >> > >> Why is *obsoleted* [RFC1771] listed as a reference? > >> > >> Why is [RFC4760] *not* listed, since this needs to work for IPv6? > >> > >> The English in this draft is quite painful in many places. Here > >> is one sentence chosen at random: > >> > >> > Taking same voice service as an > >> > example, given Provider already may provision definition of EF cod= e- > >> > point for such, signaling this code-point traffic class from PE to > >>CE > >> > along with low latency service definition, omits administrator at > >>the > >> > CE to worry about such translation. > >> > >> I'm guessing that this means: > >> > >> Taking voice service as an > >> example, a given provider might already provision the EF code- > >> point for such traffic. Signaling the code-point for this traffic > >>class > >> from PE to CE, > >> with a low latency service definition, would avoid manual operation= s > >>by the > >> administrator at the > >> CE. > >> > >> Please run ID-nits and fix the 2 errors and 11 warnings. > >> > >> Regards > >> Brian Carpenter > > >=20