Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06

Robert Raszuk <robert@raszuk.net> Mon, 14 October 2013 08:41 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 877E721E814C for <status@ietfa.amsl.com>; Mon, 14 Oct 2013 01:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Level:
X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=0.487, 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 22v2o3kC1W6C for <status@ietfa.amsl.com>; Mon, 14 Oct 2013 01:41:07 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id E83CC21E8158 for <status@ietf.org>; Mon, 14 Oct 2013 01:41:01 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id ar20so2710028iec.14 for <status@ietf.org>; Mon, 14 Oct 2013 01:41:01 -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; bh=ANCvK0V/P8+XY5swthdernFpSR6zY42iZcFQvKa8gPQ=; b=IzcoRArMTIgIl2uEgwNSu+ab5zg9z1I5/in0DdDvKVMb9u4FwlYKrECkNbpnKeSHno KYMR+8SPuhfcoHA4QZRLpfHFFFK3GYOIt6URkt7tESFN4TSiwQ/v+3fa0xSQJL8P95JO DCLUQMDab9/Y/yhFa3OvhDbm/Inw5qhFBdivH5Sm6dvMbrjD07BcI038DFd3SErkQXMm MYWVZlyT6XQJnc0XzO2/3RDWgRumiHDUUiJj8CXoslIsGLycWwSqPPm51Uj6AMSRu7bJ 2la88XzDgFgSsWDNv0pTzSlk4ZYoie/0UCHerVFy9MPv+RJ8RPtoVaxvPX/q4Z2X8ne0 5Spw==
MIME-Version: 1.0
X-Received: by 10.50.97.35 with SMTP id dx3mr12181013igb.55.1381740061429; Mon, 14 Oct 2013 01:41:01 -0700 (PDT)
Sender: rraszuk@gmail.com
Received: by 10.64.61.129 with HTTP; Mon, 14 Oct 2013 01:41:01 -0700 (PDT)
In-Reply-To: <20131014073556.GF31855@juniper.net>
References: <525639F6.8010503@cisco.com> <201310101354.r9ADsib8019588@cichlid.raleigh.ibm.com> <70D84A40-EB41-4D70-983A-DE3EB9FFE876@piuha.net> <5256E527.1030806@cisco.com> <37FBE6FA-0ECE-478A-861A-FD4CC0A8FC74@piuha.net> <20131011183222.GA30073@juniper.net> <CA+b+ERmusM-giWnBuXoAZ1xXyTpR6RMQipL6GS_HJF17TH4+3Q@mail.gmail.com> <2B72AA5C-D7A9-40E7-846D-4FBCCCAF1B1B@juniper.net> <CA+b+ERkB0fnkb41a+Mr-zDwfbVK0cJ+a4mqHU84N3KVfLeey5A@mail.gmail.com> <20131014073556.GF31855@juniper.net>
Date: Mon, 14 Oct 2013 10:41:01 +0200
X-Google-Sender-Auth: qTreFutx0oKWwdx7EZEO5gpOYSQ
Message-ID: <CA+b+ER=Z8eFJtG-cNjiCLrYJDd0tXiXOvU83eX-PXVG7bTBvUg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
To: Hannes Gredler <hannes@juniper.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "status@ietf.org" <status@ietf.org>
Subject: Re: [Status] Jari Arkko's BLOCK on charter-ietf-spring-00-06
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: Mon, 14 Oct 2013 08:41:09 -0000

Hi Hannes,

> | Yes it will be allowed to get into any network, however it is very
> | easy not to examine extension headers on such packets hence only
> | provide v6 transit as any DFZ would provide today without any SR
> | enabled.
>
> so you are advovating that internet DFZ router MUST NOT support IPv6-SR
> based forwarding as a consequence of your statement above ?

No .. not at all. DFZ routers will first check if the v6 header
belongs to infrastructure subnets. (Those will be filtered on the
edges perhaps with the exception of some heavy rate limited ICMPs - in
fact I am not sure if ICMP should support SR at all).

If the v6 header belongs to infrastructure range SID lookup will
follow if not outer v6 header will be used for forwarding (as today).

/* Now I am expecting few emails with complains ..Ohhh my ASICs can
not choose switching vector based on the outer IP header address at
line rate ;) */

> i am not sure those things can get fixed at a architectual
> level at all, given the amount of failed attempts so far.

Do we have a list or wiki page of those "failed attempts" ? In fact so
far I think the focus has been on the charter discussion which is
quite orthogonal to the SR architecture ..

Best,
r.