Re: [sunset4] Meeting in BA

"George, Wes" <wesley.george@twcable.com> Tue, 16 February 2016 18:42 UTC

Return-Path: <wesley.george@twcable.com>
X-Original-To: sunset4@ietfa.amsl.com
Delivered-To: sunset4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085341A0035 for <sunset4@ietfa.amsl.com>; Tue, 16 Feb 2016 10:42:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.229
X-Spam-Level:
X-Spam-Status: No, score=0.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 XyNNn4zC75ZK for <sunset4@ietfa.amsl.com>; Tue, 16 Feb 2016 10:42:30 -0800 (PST)
Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCE91A8792 for <sunset4@ietf.org>; Tue, 16 Feb 2016 10:42:01 -0800 (PST)
X-SENDER-IP: 10.64.163.146
X-SENDER-REPUTATION: None
X-IronPort-AV: E=Sophos;i="5.22,456,1449550800"; d="scan'208";a="530205738"
Received: from unknown (HELO exchpapp05.corp.twcable.com) ([10.64.163.146]) by cdcipgw02.twcable.com with ESMTP/TLS/AES256-SHA; 16 Feb 2016 13:38:45 -0500
Received: from EXCHPAPP03.corp.twcable.com (10.64.163.144) by exchpapp05.corp.twcable.com (10.64.163.146) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 16 Feb 2016 13:41:59 -0500
Received: from EXCHPAPP03.corp.twcable.com ([10.64.163.144]) by exchpapp03.corp.twcable.com ([10.64.163.144]) with mapi id 15.00.1130.005; Tue, 16 Feb 2016 13:41:59 -0500
From: "George, Wes" <wesley.george@twcable.com>
To: Naoki Matsuhira <matsuhira@jp.fujitsu.com>
Thread-Topic: [sunset4] Meeting in BA
Thread-Index: AQHRaOm3jblgNiaMK0SC96KtE7ta8w==
Date: Tue, 16 Feb 2016 18:41:58 +0000
Message-ID: <D2E8BB29.7E828%wesley.george@twcable.com>
References: <D2C3BADD.7AA4C%wesley.george@twcable.com> <56BD3AB7.1020701@jp.fujitsu.com> <D2E786FD.7E61A%wesley.george@twcable.com> <56C2F452.2040908@jp.fujitsu.com>
In-Reply-To: <56C2F452.2040908@jp.fujitsu.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.0.151221
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.64.163.239]
x-tm-as-product-ver: SMEX-11.0.0.1191-8.000.1202-22134.004
x-tm-as-result: No--42.822200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-ID: <74C0B21E24B08A48B0C7376BF23745C0@twcable.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/sunset4/yBtwYGArBBxEmQaPKR30gfh_CzE>
Cc: "sunset4@ietf.org" <sunset4@ietf.org>
Subject: Re: [sunset4] Meeting in BA
X-BeenThere: sunset4@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: sunset4 working group discussion list <sunset4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sunset4>, <mailto:sunset4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sunset4/>
List-Post: <mailto:sunset4@ietf.org>
List-Help: <mailto:sunset4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sunset4>, <mailto:sunset4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Feb 2016 18:42:32 -0000

Below inline with WG]

On 2/16/16, 5:05 AM, "Naoki Matsuhira" <matsuhira@jp.fujitsu.com> wrote:


>The essence of my proposal is thinking including private network with
>IPv4 private address. There are many many private network such as
>corporate network, so I believe transition technology should support
>IPv4 private address.
WG] you seem to be asserting that other transition technologies do not
support private addresses, but I don't think that this is accurate. The
way I see this, there are two transition possibilities here:
1) legacy devices/networks that must continue using IPv4 because it is
impossible/cost prohibitive to add IPv6 support
2) devices and networks that are using private IPv4 today because of
insufficient availability of globally unique IPv4, which can be enabled
for IPv6 (either dual-stack or single stack) as appropriate.

The model for this is not to find ways to prolong the existence of
IPv4-only networks, even if they're private addresses. If the situation
looks like #1, then the network works as-is today, so it can either be
shrink-wrapped at its current size, or if it needs to grow, you can put an
ALG or NAT64 gateway in front of the legacy devices so that they can reach
and be reached by IPv6-only devices. If the situation looks like #2, IPv6
is deployed, and the dependence on private IPv4 gradually falls away as
more services migrate to use IPv6. If this does not cover what you're
describing, please be much more specific about the problem you're solving
that the others do not.

>
>We know that IPv6 is beginning to spread, in the near feature, the
>situation with wide IPv6 and small IPv4 and small but many IPv4 private
>will be the reality. Looking that time, IPv6 should wind up IPv4 network
>including private address, then enable IPv6 only operation in
>infrastructure, and provide IPv4 continuous use environment as a service.
WG] it's not totally clear from the above, but it sounds like you're
proposing a method to connect IPv4-only islands over an IPv6-only network.
There are multiple existing solutions for this, including GRE or IPv4 in
IPv6 tunnels, MPLS encapsulation (L2/L3 VPNs), etc. The IETF has also
identified a need for "4PE", which is the IPv4 over IPv6 version of
RFC4798 (6PE) to do these sorts of island connections in a way that
involves less manual provisioning of tunnels. (see RFC 7439 section 3.3.2)

>
>The technical essence of my proposal is Plane ID in M46A. And I propose
>my proposal as a general-purpose technology, and may apply many IPv4
>network such as for backbone network, enterprise network, datacenter
>network.
WG] your proposal is very light on details, so it is difficult to evaluate
its applicability. Your mention of plane IDs makes me think that you're
describing a way to disambiguate overlapping private address space,
similar to the VPNv4 address used in RFC4364, which is why I mentioned 4PE
above.

>
>The difference from MAP, DSLite, 464XLat, I understand these are
>combined technology, i.e., NAT with hub and spoke Tunnel. In M46E
>(encapsulation) position, M46E and NAT combination may possible. I
>believe the decision of such combination is focusing to access network
>and main point is address sharing.
WG] DSLite is a method to encapsulate IPv4 in IPv6. It terminates on a
device that does NAT44, but it could just as easily be bypassed to serve
as a convenient encapsulation mechanism if NAT is not desired. It is
already implemented and supported, making it a more likely solution to
this problem space. If you do not believe that this will be enough, you
need to more clearly articulate your problem and why it cannot be solved
by existing transition technologies.

>
>As encapsulation technology, M46E support full mesh, and N point full
>mesh normally require N^2 configuration, however M46E-FP require N
>configuration. So I believe these proposal may contribute.

WG] possibly, but we need a better sense for when a full mesh of
interconnected IPv4 islands over IPv6 would be required such that this is
something for which we should optimize a solution.

Lastly, I don't think you necessarily need 6 separate drafts for this as
all of them are quite short, so I might suggest reorganizing it down to
one or two larger draft(s) with different sections to discuss the
different variants, and an improved problem statement and gap analysis


Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------



________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.