Re: IETF network incremental plan

JORDI PALET MARTINEZ <jordi.palet@consulintel.es> Thu, 17 November 2016 01:06 UTC

Return-Path: <prvs=112957b6f1=jordi.palet@consulintel.es>
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 E5BF0129604 for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 17:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102
X-Spam-Level:
X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=consulintel.es; domainkeys=pass (1024-bit key) header.from=jordi.palet@consulintel.es header.d=consulintel.es
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 mP-tm_kkrG67 for <ietf@ietfa.amsl.com>; Wed, 16 Nov 2016 17:06:32 -0800 (PST)
Received: from mail.consulintel.es (mail.consulintel.es [217.126.185.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A91129617 for <ietf@ietf.org>; Wed, 16 Nov 2016 17:06:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=consulintel.es; s=MDaemon; t=1479344783; x=1479949583; q=dns/txt; h=DomainKey-Signature: Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic: References:In-Reply-To:Mime-version:Content-type: Content-transfer-encoding:Reply-To; bh=2kfP8Y5RWflmA+OVWxaGeLpOs PQIMJVMntTSn/7r7KE=; b=hy6/bjpPzLycnZ8blwgbzspFOnLtKpp8GQuieg8dk OkxhgBN+bCXka9PZKEwDGEhlzsf38UgmpdnRlZ54Qs0LtthGmMBtPfq4yCsvkq/s SGt+mqGBhkUxU7Q5IAt+3FVYIWNMbWyZ1SpMsBrKKZeu5xezktUnq9SMUKur2zHe cY=
DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=consulintel.es; c=simple; q=dns; h=from:message-id; b=r8XnCtyhyVz1rkCMChSTuzWn9OuCQDdI1jXLPFLcmZHuSgep5tWO3p2NukoE vpXFOKWQh69Q1ah/G1tcwIzk2mWcU9+rEfDEi/9stWgK/Yc+VL0fop7+h LP60e4V+bbypR+liSLrH30o41LxalvO2z3kjIUKOJsDqsLm8vALGQ0=;
X-MDAV-Processed: mail.consulintel.es, Thu, 17 Nov 2016 02:06:23 +0100
X-Spam-Processed: mail.consulintel.es, Thu, 17 Nov 2016 02:06:23 +0100
Received: from [31.133.140.36] by mail.consulintel.es (MDaemon PRO v11.0.3) with ESMTP id md50005226940.msg for <ietf@ietf.org>; Thu, 17 Nov 2016 02:06:22 +0100
X-MDOP-RefID: re=0.000,fgs=0 (_st=1 _vt=0 _iwf=0)
X-Authenticated-Sender: jordi.palet@consulintel.es
X-HashCash: 1:20:161117:md50005226940::DIyG6E3S+jPqW94o:00002jPd
X-MDRemoteIP: 31.133.140.36
X-Return-Path: prvs=112957b6f1=jordi.palet@consulintel.es
X-Envelope-From: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: ietf@ietf.org
User-Agent: Microsoft-MacOutlook/f.1b.0.161010
Date: Thu, 17 Nov 2016 10:06:16 +0900
Subject: Re: IETF network incremental plan
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: IETF discussion list <ietf@ietf.org>
Message-ID: <4B5823BC-1FE1-4395-A353-FE5AED8C41E3@consulintel.es>
Thread-Topic: IETF network incremental plan
References: <0C5BCD32-2D2A-42B9-8DEA-A1E1A527A8BB@consulintel.es> <m2zikzq7tg.wl-randy@psg.com>
In-Reply-To: <m2zikzq7tg.wl-randy@psg.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/TZOXWFb3v7kfGu-sQbu_sPPUEGs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: jordi.palet@consulintel.es
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, 17 Nov 2016 01:06:34 -0000

Hi Randy,

In my opinion the primary goal is to have everybody getting the work done, then testing our own protocols. Non-goal is to have individuals own stuff tested.

Also, I’m speaking only about the main Wireless SSID. We can keep other SSID and the terminal room Ethernet ports, pure dual stack as we have today, which allows testing your own stuff and sorting out possible issues in case of “emergency” or major breach of our tests.

NAT64 is not useful because you need to manually write down what works, what not. That’s why I’m suggesting having a first hop router with, for example a modified OpenWRT version of 464XLAT, which logs each use of CLAT and PLAT. This way we could get an automatic list of what are the apps that fail to work with IPv6, which ones work with only PLAT, and which ones need CLAT.

Regards,
Jordi


-----Mensaje original-----
De: ietf <ietf-bounces@ietf.org> en nombre de Randy Bush <randy@psg.com>
Responder a: <randy@psg.com>
Fecha: jueves, 17 de noviembre de 2016, 9:16
Para: Jordi Palet Martinez <jordi.palet@consulintel.es>
CC: IETF discussion list <ietf@ietf.org>
Asunto: Re: IETF network incremental plan

    last evening i was carrying a question from the noc team but my position
    in the mic queue was preempted by more important people.
    
    but essentially, before we make tactical decisions we would like to know
    what the purpose and goal of the meeting network is.
    
      o folk just want to get work done, and the net should bloody well work
    
      o i want to forward test internet futures: ipv6, auth methods, crypto,
        ...
    
      o i have my own stuff i want to test (which may need inbound sessions)
    
      o network?  what network?
    
    in the nat64 case, are we trying to validate the well-known lists of
    what does not work over nat64, spotify, many vpns, ...?  if it is
    because we think we can modify nat64 to ameliorate the problems, this
    would be brilliant.
    
    if we know what the goals are, we should be able to meet them.  so far,
    the assumption is that
    
      o the primary goal of the meeting netowrk is for attendees to get work
        done
    
      o nats breaking applications and inbound connections would be
        considered as breakage
    
      o we do want to support occasional experiments, both non-disruptive
        and visible (remember the v6-only plenary?)
    
      o but basically, i just want my mtv
    
    randy, not speaking for anyone else
    
    
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.