IETF Logo Mail Archive

Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08

"Leddy, John" <John_Leddy@comcast.com> Thu, 30 March 2017 11:07 UTC

Return-Path: <John_Leddy@comcast.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2840F129471; Thu, 30 Mar 2017 04:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Hzis7LmUkRBH; Thu, 30 Mar 2017 04:06:57 -0700 (PDT)
Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) (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 8B961127A97; Thu, 30 Mar 2017 04:06:57 -0700 (PDT)
X-AuditID: 60721c4c-b2dff7000000bcc0-91-58dce6ce975d
Received: from VAADCEX43.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher AES256-SHA256 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 10.E3.48320.EC6ECD85; Thu, 30 Mar 2017 07:06:56 -0400 (EDT)
Received: from VAADCEX41.cable.comcast.com (147.191.103.218) by VAADCEX43.cable.comcast.com (147.191.103.220) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 30 Mar 2017 07:06:53 -0400
Received: from VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268]) by VAADCEX41.cable.comcast.com ([fe80::3aea:a7ff:fe12:e268%19]) with mapi id 15.00.1263.000; Thu, 30 Mar 2017 07:06:53 -0400
From: "Leddy, John" <John_Leddy@comcast.com>
To: Mark Townsley <mark@townsley.net>
CC: Tim Chown <tjc@ecs.soton.ac.uk>, "draft-ietf-6man-rfc2460bis.all@ietf.org" <draft-ietf-6man-rfc2460bis.all@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Topic: IETF Last Call conclusion for draft-ietf-6man-rfc2460bis-08
Thread-Index: AQHSqOd8Ap6Hay13uEWcjbPxwh2xd6GssVmAgABnjYCAAEsUAP//1bD/
Date: Thu, 30 Mar 2017 11:06:53 +0000
Message-ID: <619B8C8A-066E-4C5B-A462-DF109E39DA71@cable.comcast.com>
References: <599257D7-532D-4512-929B-D124623EAF35@ericsson.com> <6B662F87-B0E6-4613-B406-8A22CA95DFA5@cisco.com> <4917F161-2EC8-43E0-AF4C-BFAEE44A492C@cable.comcast.com> <DF41D301-8760-41E9-9ED4-2D28F394C070@ecs.soton.ac.uk> <EMEW3|eed7c9a1e88b01b870b0ed916a75b22ey2Y69n03tjc|ecs.soton.ac.uk|DF41D301-8760-41E9-9ED4-2D28F394C070@ecs.soton.ac.uk>, <A112F912-A7FC-4682-A043-4430DD578306@townsley.net>
In-Reply-To: <A112F912-A7FC-4682-A043-4430DD578306@townsley.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsWSUOxpoXvh2Z0Ig+VTVCxevb3GZvFs43wW i5dn3zNZTDvwgMni0J7nbA6sHn/XuXosWfKTyeP+tIlMAcxRXDYpqTmZZalF+nYJXBkXPsxg K3jBVrH1bGED4yLWLkZODgkBE4nrf+azdDFycQgJbGeSuNFxjRXCOcQo0fbvLhuEc5JRYt/T D8wgLWwCOhIzpl0DaxcRUJVYe+UhM0gRs8A+Rol3H0+CJYQFPCQmbbrGAlHkKbFu42EgmwPI dpPo/hEOYrIA9e66aQJi8gq4SBzaUQKxaiqzxIKGOYwgnZwCDhLzGnaA2YwCYhLfT61hArGZ BcQlbj2ZzwTxgYDEkj3nmSFsUYmXj/9BfWYgsXXpPhaIeh2JBbs/sUHY2hLLFr4Gq+cVEJQ4 OfMJC0S9pMTBFTdYJjCKz0KyYhaS9llI2mchaV/AyLKKUa4sMTElOTcjv7TEwEgvOTEpJ1Uv OT83ObG4BERvYgTFY5GMzw7GT9M8DjEKcDAq8fBu3XsnQog1say4MhcY3BzMSiK83E+AQrwp iZVVqUX58UWlOanFhxilOViUxHm9bt6KEBJITyxJzU5NLUgtgskycXBKNTBOFp9le+rutAUO /6/ulkw7M6PdS7Ou1krwXrjJicV/psScWrT/XCljsGwA49ZulV3ea3cxyZ4O/3AyyWpf6POp 0f5t57Y9qeZPyNrDwLRcRsFUuelm5akNih7PTWL6fJY0q3Fw5b189eTT0SlZQgyLRC/2L1Hp meYuOf07O2tRiNPODyEpD08osRRnJBpqMRcVJwIAPuhLg8MCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/oW1KNDHEmuooGZnJ4ar3PWEB16I>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 11:07:00 -0000

The issue is the encap/decap pair - like an old circuit model.

Do we add the encap/decap function into a Domain doing native SRv6 and the complexity of choosing which to use - into all the vm's?  Or do we extend the new SRv6 domain to the legacy infrastructure.   If we do this, there is no tunnel.  There is no encap/decap pair - you need to proxy for the legacy gear/services.

John

> On Mar 30, 2017, at 4:38 AM, Mark Townsley <mark@townsley.net> wrote:
> 
> 
> 
>> On Mar 30, 2017, at 12:09 AM, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
>> 
>> Understood, but why do you require direct insertion rather than using encap as per 2460bis?
> 
> The same reason we have MAP-T and 464xlat. 
> 
> - Mark
> 
>> 
>> Tim
>> 
>>> 
>>> John Leddy
>>> Comcast
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>

v2.23.0 | Report a Bug | By Email