Re: [spring] Question about SRv6 Insert function

Robert Raszuk <robert@raszuk.net> Fri, 06 September 2019 08:37 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCDCA12008F for <spring@ietfa.amsl.com>; Fri, 6 Sep 2019 01:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
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 csI0KZ2tYbPM for <spring@ietfa.amsl.com>; Fri, 6 Sep 2019 01:37:00 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 4B97D120099 for <spring@ietf.org>; Fri, 6 Sep 2019 01:37:00 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id i78so4845574qke.11 for <spring@ietf.org>; Fri, 06 Sep 2019 01:37:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dZVPvcZtmrrQTZWumtJ5QHoZrBnDBkGgpS50Yr6YEwE=; b=GxGlAVO4yc8GeqLiX5HSj3LRZVpTFbCFXTW6Jp9b4eZWJh8JT26RzsP8lYdrF41IQ7 hBrnT8jpmaz0Or2cJKRspgZpxjc5z+RBXQbiX3xVSTzgpxcaGd14EBpr1+9JxmvRgT+O Lpx7se+Xo1XmuuXOcVroLFX4JQVHVh1a2f2JcEyujfwizeHj/9MqwD/QYx5sKSAQPrGG C0M+2K5MsSPm/+30unZ7GW4EsnuhdA32SzZT7tX5I2UwC2XM4qlC0wfU17tFTRt29OWF u9FNwqB7rx0J+0nZLN1+9DFEei+ZBqnP29aM88XV+RAEOCLQqgucgmLRn5Bm5puK/xXI GchA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dZVPvcZtmrrQTZWumtJ5QHoZrBnDBkGgpS50Yr6YEwE=; b=iE5A0vqdGtNtS9nltnGjYU+1Wm3jmnSlx2NVp9MqNYupZtyaz/oEpQ9h54mfy2w6iU EQT5avU9dN9Fw3/tmRJlPJF0VosXF0+JvC/c1Gzcc16ShhEtobcwoda0h/z6ViV8qwGB q8oIO/pxBp5LyB88WoEb0FoNjOkNgIbV2vXZFP69ryQXNvKYXEgRR0SsVR4CyAG+apdi GEXXPpD3mabSgZQhrxP4lUG3CkSmBPTsZEVJ7Ld7X8/qenTmJGEc24C/ISFV6zEujsb/ +5cNyvHLw5hgvLjPrp00pWAHTMrwlTfnox28vrneZSAPF7np+5bo9miXoXJYag+Pmt0t Ye2Q==
X-Gm-Message-State: APjAAAWwlgaxrMmgKc2ksSESSPeOyHhb1LybyxD3UGbZaCqPm6bq7Obj CkF0TVIl/FaWZ7w/2uXpz+/qf6pAqH3yj95nqUWIIM1JdN4=
X-Google-Smtp-Source: APXvYqxALf4brGWPr0JVx91hw2vlFoCG0CgT+0OwGUNOqO/KwiJC6iYtYvvTqHPde3XdiPda5XbGVnQgJdMXgqSvEAc=
X-Received: by 2002:a37:a7c5:: with SMTP id q188mr5630243qke.445.1567759019342; Fri, 06 Sep 2019 01:36:59 -0700 (PDT)
MIME-Version: 1.0
References: <HK0PR03MB3970C6DCC635E7CD802D65FDFCBD0@HK0PR03MB3970.apcprd03.prod.outlook.com> <BYAPR05MB54636A2332FED916A26A6F14AEBD0@BYAPR05MB5463.namprd05.prod.outlook.com> <3e31873a-278a-2154-0e71-4d820bba323d@gont.com.ar> <4012D854-2F10-4476-951D-FFFE73C5083C@gmail.com> <cb2f56f8-acdc-d68d-0878-9609cb3d7b1b@gont.com.ar> <28214_1567694772_5D711FB4_28214_238_1_53C29892C857584299CBF5D05346208A48BFA9F3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <b83a7060-0517-c6ad-f6b0-bc9e61e4667f@si6networks.com> <A6FA74AC-F349-4F01-A86A-949870134779@cisco.com> <BYAPR05MB546363BF8D7D1EC848EB3103AEBA0@BYAPR05MB5463.namprd05.prod.outlook.com> <CA+b+ERmdCB9RVstq2sUnkYLM29ayE6jZuWARQv7HRbsMW_Tu-w@mail.gmail.com> <VE1PR03MB54229769DB4A7F4A880E628CEEBA0@VE1PR03MB5422.eurprd03.prod.outlook.com>
In-Reply-To: <VE1PR03MB54229769DB4A7F4A880E628CEEBA0@VE1PR03MB5422.eurprd03.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 6 Sep 2019 10:36:49 +0200
Message-ID: <CAOj+MMGkkXqJHKyRqgKW2oF4650QREcLf2kJy_8d9z2MEHMoVw@mail.gmail.com>
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Cc: Robert Raszuk <rraszuk@gmail.com>, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>, Fernando Gont <fgont@si6networks.com>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000710e090591de5749"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/oBDDucOQzIyVReZ_MP-q8PSAE3U>
Subject: Re: [spring] Question about SRv6 Insert function
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Sep 2019 08:37:03 -0000

> what the current drafts do – is fundamentally rewrite the ipv6 protocol

I think you are giving small team of focused engineers way too much credit
here :)

What they tried to do is to merely make sure that if someone decides to use
IPv6 they have a chance to not only have functional parity with other
transports, but also could go a bit forward and turn v6 transport into more
innovation.

In that respect objectives of both SRv6 and SRv6+ are identical.

Now having seen stones being smashed at those who try to actually improve
IPv6 I am personally even more discouraged. It is now becoming even more
obvious why adoption of IPv6 in enterprise networks, enterprise compute
clusters or end users is so marginal after 25+ years ....

Cheers,
R.


On Fri, Sep 6, 2019 at 10:27 AM Andrew Alston <
Andrew.Alston@liquidtelecom.com> wrote:

> Robert, my problem here is – I believe that there could have been common
> ground found between various proposals except – what the current drafts do
> – is fundamentally rewrite the ipv6 protocol – the changes in the address
> semantics (twice over in incompatible ways between the programming draft
> and the uSID draft) – the violations of rfc8200 – etc – mean that – it
> becomes very hard to find a solution when there is a massive philosophical
> difference – where the philosophical difference is routed in – a v6 address
> is a 128bit identifier as defined by rfc4291 – vs – an address is well –
> insert a long list of other things on top of that.
>
>
>
> We spent the better part of 25  years getting IPv6 to what it is – and now
> – fundamentally – there is an attempt to rewrite the very thing that IPv6
> is – and therein lies one of my major problems – and no matter how many
> times I have raised the semantic issues – it seems to be an issue that is
> being blindly ignored.
>
>
>
> Tell me – how do you do aggregation of addresses in the network
> programming draft – aggregate – lose the function bits
>
> How do you do uSID in the network programming draft – shift – lose the
> function bits – or – retain the entire stack – and lose the entire point of
> uSID in the first place – to solve the overhead
>
> By rewriting the IPv6 specification in the way this does – it introduces
> draft after draft to cater for what is essentially no longer IPv6 – vs –
> finding a way to work within the IPv6 specification to produce the same
> functionality as is required in a compatible manner that is more efficient.
>
>
>
> Therein I believe lies half the root of this – on one side – you have an
> attempt to redefine an entire protocol that was 25 years in the making in
> the image of what one group of people believe it should be – on the other
> side – you have an acknowledgement of required functionality – and an
> attempt to provide it while not rewriting the entire protocol in the
> process.
>
>
>
> Andrew
>
>
>
>
>
> *From:* ipv6 <ipv6-bounces@ietf.org> *On Behalf Of *Robert Raszuk
> *Sent:* Friday, 6 September 2019 11:18
> *To:* Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>
> *Cc:* Fernando Gont <fgont@si6networks.com>om>; spring@ietf.org;
> 6man@ietf.org
> *Subject:* Re: [spring] Question about SRv6 Insert function
>
>
>
> Ron,
>
>
>
> > They remind us that draft-ietf-spring-network-programming are far from
> maturity.
>
>
>
> To me it actually highlights something quite contrary. It is that some
> folks are pretty far from appreciating or even grasping the value of the
> proposal.
>
>
>
> In your other note you have extensively elaborated well on how to
> effectively kill innovation in IETF. If we would be following your advice
> there would be almost non documents which build on former work and update
> former work.
>
>
>
> But most importantly documenting something does not force anyone to
> actually use it if they choose so. This entire smoke about header insertion
> from what I have been told has some technical concerns about real source
> awareness about say MTU issues. Well for one if I am doing insertion in my
> network I better make sure I do not drop the packet based on the MTU. It is
> so basic ... of course I must clean up when I fwd the packet to other
> domain but this is basic network hygiene.
>
>
>
> In the same time folks are happy to encap + add EHs, DOs etc ... on the
> grounds that src of the encap will be in the packet. Is this sufficient ..
> even if ICMP is sent to such src (domian ingress) I bet such domain ingress
> will not notify the original packet src anyway. And with encap the packet
> gets much bigger anyway.
>
>
>
> But I was not part of v6 creators and I think I will keep it that way
> based on that little thread we had here :)
>
>
>
> Best,
>
> R.
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>