Re: [Status] SPRING Charter

Robert Raszuk <robert@raszuk.net> Wed, 16 October 2013 19:28 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: status@ietfa.amsl.com
Delivered-To: status@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3827811E8150; Wed, 16 Oct 2013 12:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.429, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg4vvLfq92xa; Wed, 16 Oct 2013 12:28:16 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 813CF11E81DB; Wed, 16 Oct 2013 12:28:16 -0700 (PDT)
Received: by mail-ie0-f176.google.com with SMTP id u16so2123483iet.7 for <multiple recipients>; Wed, 16 Oct 2013 12:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=p/2Bx3AVeQ0aBGlZK/zpShhy70ThaaApBf38Pv034WI=; b=NpleWIn+FRt1sKVVG50ip/cADj4Kx3tOGqX29K5X7J1EIe/w9bSUrQnnnCtIb/ZZsA AvzStpAs2XFIWC9WZcpealUw5gnWrM7OxE6EMQ5JqjD0TmP3LWt1K2tShEAx0fQysvFo DrUcdb75B59YxseWkpSZ715/Wu4tOh056owBJSW9HxiUIcFs4mxkg3R77u1cQ12WicGv L14aGNzgUK9PBsxGLQmWwS2FBlojQnefCnc6vSLI/HrOhEq13mh19O5dNHo6FqSsKzpM hZMkGGX1w0ijOMkXZG8K5cBw/2zyz9cn5eRUl6zxhU6diCSEWCrZlS0XNCCGezFqe0dW dvJQ==
MIME-Version: 1.0
X-Received: by 10.42.84.130 with SMTP id m2mr2930330icl.16.1381951695511; Wed, 16 Oct 2013 12:28:15 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Wed, 16 Oct 2013 12:28:15 -0700 (PDT)
In-Reply-To: <7A710072-199D-456D-9DB3-C7DBAC0AA0A2@piuha.net>
References: <52584CCA.8000902@cisco.com> <201310151346.r9FDkSIl023262@cichlid.raleigh.ibm.com> <525ECA07.2070207@cisco.com> <9C5D9C4D-F90E-48B3-A005-3DAC1EEC378F@juniper.net> <AA242DD4-AEE1-465B-8A3C-8887FA1542BB@piuha.net> <CA+b+ER=P_aBwJMOgbLHgMHceBU=QbMQT=d_A6DRfDroHMR-F-g@mail.gmail.com> <7A710072-199D-456D-9DB3-C7DBAC0AA0A2@piuha.net>
Date: Wed, 16 Oct 2013 21:28:15 +0200
X-Google-Sender-Auth: zn_CVN8foYBh1XL_0eNIjQVFqxA
Message-ID: <CA+b+ER=Nd0YAH4rpym_3DfyV7+D-CrchPOxrKM3th-89HkS3kg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Jari Arkko <jari.arkko@piuha.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: "iesg@ietf.org" <iesg@ietf.org>, "status@ietf.org" <status@ietf.org>
Subject: Re: [Status] SPRING Charter
X-BeenThere: status@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." <status.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/status>, <mailto:status-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/status>
List-Post: <mailto:status@ietf.org>
List-Help: <mailto:status-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/status>, <mailto:status-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Oct 2013 19:28:17 -0000

If you accidentally turn on SR then you have no SIDs in your thousand
machine network to forward to hence I do not see the issue. The
packets will be forwarded to the outer destination v6 address (same as
today).

I think perhaps disconnect is that extension header is not to be a
normal v6 header however packet destination (just like today in
transit) could be regular v6 address.

It's however not the charter discussion I think ....

Many thx,
R.




On Wed, Oct 16, 2013 at 9:11 PM, Jari Arkko <jari.arkko@piuha.net> wrote:
> Robert - I think we discussed this previously. One of my issues was that it is not just your well-protected network that is in danger. It is also my network with thousand machines, with one accidentally turned on to accept the new headers. The current text in the charter resolves that concern, and I'm not sure I want to have headers that wouldn't be able to do protect against this… particularly when the cost is minimal.
>
> Jari
>