Re: [OPSAWG] Suresh Krishnan's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-11: (with DISCUSS)
Duzongpeng <duzongpeng@huawei.com> Thu, 25 January 2018 03:06 UTC
Return-Path: <duzongpeng@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E76C12D7EE; Wed, 24 Jan 2018 19:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level:
X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jOOWjimqPFI; Wed, 24 Jan 2018 19:06:00 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70D0D12D7EA; Wed, 24 Jan 2018 19:06:00 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 54C867F133C85; Thu, 25 Jan 2018 03:05:56 +0000 (GMT)
Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 25 Jan 2018 03:05:57 +0000
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0361.001; Thu, 25 Jan 2018 11:05:47 +0800
From: Duzongpeng <duzongpeng@huawei.com>
To: Suresh Krishnan <suresh@kaloom.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-opsawg-capwap-alt-tunnel@ietf.org" <draft-ietf-opsawg-capwap-alt-tunnel@ietf.org>, Tianran Zhou <zhoutianran@huawei.com>, "warren@kumari.net" <warren@kumari.net>, "opsawg-chairs@ietf.org" <opsawg-chairs@ietf.org>, Tianran Zhou <zhoutianran@huawei.com>, "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: Suresh Krishnan's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-11: (with DISCUSS)
Thread-Index: AQHTlSL+SHQ9VAH/hE2yWXxzxBhY7KOD4zRQ
Date: Thu, 25 Jan 2018 03:05:46 +0000
Message-ID: <BAFEC9523F57BC48A51C20226A558957648239C7@nkgeml514-mbx.china.huawei.com>
References: <151680555709.25672.9561537628046201312.idtracker@ietfa.amsl.com>
In-Reply-To: <151680555709.25672.9561537628046201312.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.149.226]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/TOdfqmh2kDsPmhY1EI1230h8tBo>
Subject: Re: [OPSAWG] Suresh Krishnan's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-11: (with DISCUSS)
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 03:06:02 -0000
Hi, Suresh Krishnan Thank you for propose the problem. I have checked the RFC[5844]. It did mention two kinds of UDP Encapsulation Modes, IPv4-UDP and IPv4-UDP-TLV. However, in the Section 4 "IPv4 Transport Support", it said: * IPv4-UDP-TLV (payload packet carried in an IPv4 packet with UDP and TLV header) and IPv4-GRE (Payload packet carried in an IPv4 packet with GRE header). Refer to [GREKEY]. If payload protection using IPsec is enabled, the ESP header follows the outer IPv4 header, as explained in Section 4.3. So, the IPv4-UDP-TLV is actually defined in [GREKEY], i.e. RFC [5845] named Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6 In RFC [5845], Figure 5 shows the "TLV-Header UDP-Based Encapsulation Header Order", [IPv4 Header] [UDP Header] [TLV Header] [GRE Header] [Payload - IPv6 or IPv4 Header] Upper Layer protocols Figure 5: TLV-Header UDP-Based Encapsulation Header Order Hence, in my understanding, Tunnel-Type is 4 means the IPv4-UDP Encapsulation Mode, not the IPv4-UDP-TLV Encapsulation Mode. To resolve the problem, I can update the draft if no objections. Old: 4: PMIPv6-UDP. This refers to the UDP tunneling encapsulation described in [RFC5844]. New: 4: PMIPv6-UDP. This refers to the IPv4-UDP tunneling encapsulation described in [RFC5844]. If any future problems, please connect me. Thanks. Best Regards Zongpeng Du -----Original Message----- From: Suresh Krishnan [mailto:suresh@kaloom.com] Sent: Wednesday, January 24, 2018 10:53 PM To: The IESG <iesg@ietf.org> Cc: draft-ietf-opsawg-capwap-alt-tunnel@ietf.org; Tianran Zhou <zhoutianran@huawei.com>; warren@kumari.net; opsawg-chairs@ietf.org; Tianran Zhou <zhoutianran@huawei.com>; opsawg@ietf.org Subject: Suresh Krishnan's Discuss on draft-ietf-opsawg-capwap-alt-tunnel-11: (with DISCUSS) Suresh Krishnan has entered the following ballot position for draft-ietf-opsawg-capwap-alt-tunnel-11: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-alt-tunnel/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3.2. This should be easy to resolve but I would like this to be disambiguated before publication. RFC5844 specifies *two* different options for UDP encapsulation IPv4-UDP and IPv4-UDP-TLV. Please clarify which of these modes is intended when the Tunnel-Type is 4 4: PMIPv6-UDP. This refers to the UDP tunneling encapsulation described in [RFC5844].
- [OPSAWG] Suresh Krishnan's Discuss on draft-ietf-… Suresh Krishnan
- Re: [OPSAWG] Suresh Krishnan's Discuss on draft-i… Duzongpeng