Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt

Robert Raszuk <robert@raszuk.net> Thu, 30 November 2017 22:07 UTC

Return-Path: <rraszuk@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871B1126B6E; Thu, 30 Nov 2017 14:07:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 BTZcTVgI5fWk; Thu, 30 Nov 2017 14:07:46 -0800 (PST)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 113171200CF; Thu, 30 Nov 2017 14:07:46 -0800 (PST)
Received: by mail-wr0-x22f.google.com with SMTP id x49so8118150wrb.13; Thu, 30 Nov 2017 14:07:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Y7IcYBBPRmF5QODGGTQrj60e6pLLwQ5KRbzFjH3/0Rw=; b=G9w/WAV/DMktKjaW6X7EPqMXIMaI/4hk6OaM/XYK9SRZ0lnjOQgG7i1nJjeC3XZIiJ XiR+QFl1NYO88d1W82J6iKNl0xtPKpKzY591LxoI1d2RwFZTTlycXNCLCPD+RLHPWPFz F4Tb3psH5Y67xyNNMopvKRfA76hxuf9meHqVMVfVBd5u4QuGdAmrMyHVutdigt7CmpEY iq2/ZBMYXTDLPd1rI76cT2ttH1zY9qweqbbTBboOiA4QnESUFQHOjdmwjSXidGaNwdMt sev63EeVlPmknkf9rNSAPdTQhOmlkVKfpL7f2AWUFgvNM8wrNKsz5wQOyUZGk02wANbT bh8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Y7IcYBBPRmF5QODGGTQrj60e6pLLwQ5KRbzFjH3/0Rw=; b=T2pmbzN/dd8vALZzJK6e+NgTlf6SxIJE1eE/d+fUQVWfazkKcHvTAIt+EZ6n8j+1fC mrW8grardbe8d8LMJjWeU815z8EmUgAZxXyAsVcqpu7wfZiVD9wxIOuTZrwo8uPZLFxw MXeLl5/02Li/3COaG7hPk+8kmcDuS/ysa4/Di3WrcttFw7GHcjgPZxmew4cI3/BLJjvn RsCjeGWNounU7oWynb8jj4nEeQtRL4CyQyPtwqklwmvhAzkYVoLUHuD+5sID2uAiEEkr qU/xU1qPQFWH/6raQ5FrnYSiY49jLmGUaHxiWY9FELxEC0CaK0WtBXPCVCaFUjEmpvWV +Q5g==
X-Gm-Message-State: AJaThX53Z1GcIF7Npu7gi2m5fcIUlyRxehJnVMqwNWWn3MUWEU7wU8O4 LhRx9ddagppIdCew6nUWV7bXZTvNei1zVsdRj5k=
X-Google-Smtp-Source: AGs4zMZ8dl1ZTOOhV3nit0zlCwUAGTddjWm+iHJil+LttMn8N46HaFtmibF6cRpsfOebfD9yo5KK7Oj+Asend4SIxn4=
X-Received: by 10.223.182.81 with SMTP id i17mr3230730wre.224.1512079664282; Thu, 30 Nov 2017 14:07:44 -0800 (PST)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.28.54.217 with HTTP; Thu, 30 Nov 2017 14:07:43 -0800 (PST)
In-Reply-To: <CALx6S37MuMUbL+JBrBEeqrwX_A7+3UX4YcHs011GjuEqWQ4q9w@mail.gmail.com>
References: <151120281628.21912.1099097760493570225@ietfa.amsl.com> <4ca3fd6b-4cd6-f6ac-ce03-415c2c9a4c3c@gmail.com> <f4425076-2f76-5713-2819-9d26671d56bb@si6networks.com> <4E92F160-C586-4C7B-BAEF-97C204856A8A@employees.org> <bc9d7f57-8687-7f85-8ac3-49751683232b@si6networks.com> <CA+b+ERnKbRXgFycgKd7EXMVvS1Mu_RTC5tfPbNE781TDZ49rYA@mail.gmail.com> <CALx6S34XAA7Fo96Es9z1Yz+Eo9XdWvPHXmCAcw_WSzP8JNjKuQ@mail.gmail.com> <CA+b+ER=6AJAKY-7YREQXv6VQ7XSAQrpDd-=bcqA2hLUXSKq_Mg@mail.gmail.com> <CALx6S37MuMUbL+JBrBEeqrwX_A7+3UX4YcHs011GjuEqWQ4q9w@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 30 Nov 2017 23:07:43 +0100
X-Google-Sender-Auth: WFihk51e3Tr7Dj6QHaj85UcLh3s
Message-ID: <CA+b+ERmxW9fwYx1nn1am=qdsROxX6nmnd_7vFRV9d2cZpeVrZw@mail.gmail.com>
Subject: Re: I-D Action: draft-voyer-6man-extension-header-insertion-02.txt
To: Tom Herbert <tom@herbertland.com>
Cc: Fernando Gont <fgont@si6networks.com>, draft-voyer-6man-extension-header-insertion@ietf.org, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="f4030439df9043039f055f3a7b50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/CDmK0JWS2taMA2uH0F_YGoywH-o>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Nov 2017 22:07:47 -0000

Tom,

The biggest advantage of SRv6 in contrast to SR-MPLS is that the SRH (one
or more) are not modified through the SR applicability of the packets.

So node which understands SRv6 can generate ICMP to both src of the packet
(poor host) as well as ingress node in SR domain (as it is explicitly
listed in Ingress Node TLV of first SRH). Node which does not understand
SRv6 will likely only send it to original src .. but this is a feature not
a bug. This is how traceroute works.

If you do encap how will host now see all the nodes on the way traceroute
or tracepath ? Do you think that hosts admins will be happy to be blinded
by 6man ?

Btw I am not the one who ever claimed applicability to "controlled
networks" or "wall gardens" so don't try to use that one with me :)). For
me the much bigger question is what should go into data plane and what is
better to go in control plane. We may end up with both and let
customers/operators choose. But hand waving that doing innovation in data
plane is scary is not the approach I would endorse.

We would be still doing token ring or FDDI ....

Cheers,
R.


On Thu, Nov 30, 2017 at 10:54 PM, Tom Herbert <tom@herbertland.com> wrote:

> On Thu, Nov 30, 2017 at 1:25 PM, Robert Raszuk <robert@raszuk.net> wrote:
> > Tom,
> >
> > Imagine the case where packets are subject to go via service chains. I
> can
> > steer the packet to the router which has service nodes connected to it
> but
> > original src address may be used to decide which service given packet is
> > subject to take.
> >
> > Sure I can impose an SR function and map it up front such that the router
> > above would never need to inspect src address, but why to construct such
> > architecture which only allows limited set of network programming as
> opposed
> > to offer the choice on how to setup things by network operators ?
> >
> Robert,
>
> Because the architecture, or at least protocol, is not correct.
>
> Suppose a device inserts an EH into a packet that downstream causes
> the packet to be dropped and generates an ICMP error which goes back
> to the source. What is a source host supposed do with this? It might
> be able to determine that it didn't send the EH, and if it's lucky it
> might even be able to parse the offending EH and maybe even sees the
> problem that caused the error. But then what? How does the host tell
> the network to stop mucking with its packets so that they no longer
> get dropped and the source host doesn't get blamed?
>
> ICMP handling is just one of several issues that needs to be
> addressed. If the only answer is that these aren't concerns because
> the protocol is only deployed in controlled networks, then I claim
> that's nothing more than hand waving which is not robust and doesn't
> scale.
>
> Tom
>