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