Re: [Int-area] draft-ietf-intarea-tunnels

Lucy yong <lucy.yong@huawei.com> Mon, 02 November 2015 08:59 UTC

Return-Path: <lucy.yong@huawei.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A481B3521 for <int-area@ietfa.amsl.com>; Mon, 2 Nov 2015 00:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 A_ExVwpLQF92 for <int-area@ietfa.amsl.com>; Mon, 2 Nov 2015 00:59:18 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971E21B351E for <int-area@ietf.org>; Mon, 2 Nov 2015 00:59:17 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CDJ95052; Mon, 02 Nov 2015 08:59:15 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 2 Nov 2015 08:59:15 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Mon, 2 Nov 2015 00:59:09 -0800
From: Lucy yong <lucy.yong@huawei.com>
To: Joe Touch <touch@isi.edu>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: draft-ietf-intarea-tunnels
Thread-Index: AdEMOrWu53lS9XlmSGiq1iu9C8boGQAXlnQAAelD9iAARh7hAAADKmAg
Date: Mon, 02 Nov 2015 08:59:08 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D57203CCE@dfweml701-chm>
References: <2691CE0099834E4A9C5044EEC662BB9D571FF224@dfweml701-chm> <56282A02.5000408@isi.edu> <2691CE0099834E4A9C5044EEC662BB9D572034A0@dfweml701-chm> <5636C5EC.9040808@isi.edu>
In-Reply-To: <5636C5EC.9040808@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.194.187.169]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/int-area/3Q6LaRFqNMKb8h8P9BplJB442Os>
Subject: Re: [Int-area] draft-ietf-intarea-tunnels
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2015 08:59:19 -0000

> The draft describes the arch and req. for use portion of the Internet 
> providing a link to other portion of the Internet.
> 
> There are also applications that using portion of the Internet 
> provides many links to individual private IP networks, i.e. one link 
> to one private IP network. e.g. network virtualization.

Network virtualization has many - often inconsistent and mutually conflicting - definitions. 
[Lucy] So a proper architecture helps resolving the mess.
E.g., IMO, any network that includes tunnels as links includes network virtualization. A truly virtual network is one composed entirely of tunnels, IMO.
[Lucy] not sure. 

> It would be useful for your draft to explicitly distinct two cases and 
> point out the requirements for both cases. For example, ICMP usage.

I don't see them as distinct. Whether a network is connected to the public Internet or not is less important than whether IPv4 or IPv6 is used as the network layer.
[Lucy] Less important does not mean not an important. Agree Ipv4 or Ipv6 as underlay is important one.

Can you clarify how the second case might be distinct from the first regarding ICMP use or any other aspect?
[Lucy] One example, in second case, upon receiving ICMP, the router that ingress tunnel terminate has to determine which network the msg need to be sent out while the first case only has one network over the tunnel. In second case, these networks using the same IP tunnel run in ship-in-night mode. In other words, dedicate tunnel vs shared tunnel. 

Lucy 

Joe


> Regards,
> Lucy
> 
> 
>  
>