Re: [spring] Question about SRv6 Insert function

Robert Raszuk <rraszuk@gmail.com> Fri, 06 September 2019 15:56 UTC

Return-Path: <rraszuk@gmail.com>
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 AB7A81200E0; Fri, 6 Sep 2019 08:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 3roBbvnf-pyo; Fri, 6 Sep 2019 08:56:04 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 0FB9B120026; Fri, 6 Sep 2019 08:56:04 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id p3so3724254pgb.9; Fri, 06 Sep 2019 08:56:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ISG4qAtTCOQjAlJunjDBpG267po45emMNW77dZuoj8Y=; b=boymPC/n3aOtIUD4ZrNx4WosEf8JnEj6MHDY+VDlDXwsiRgxf0HVmGbzFITLHi+Ve3 cSSxDNGZaEcpuvcuFxSicreBP7BWOCEyVEL+l4ByW3Cn2i94CLDw9QGvwdAz563ekeff xvKoFEgpoQip9xLSj1cz5+R5zwlYNE2L5YUf7n7xfWaHKx4gtunGI1CfjTW8euv8h54T QTMCvAqVvXo8U8R1XdKvwxKW/sbpYBTYCwfHCYcdEZj6YmDQDwoN3NrdTTQBTtOT0nKV NG57ayU/xoJYh3u12TA08S9VMcfOCkKnGVzURHoLxQzIG/CFL/vRVOEZIb4fePKbKCDj MiMg==
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=ISG4qAtTCOQjAlJunjDBpG267po45emMNW77dZuoj8Y=; b=hRRcJFg6yaSCQyKlcC1cIIHktBOlu48NjjdYvO09x06TOyEGat92uccx0Xuaw8LIOQ sP8nYWWi9mswpTXV4vfk72Uh/SaEscHiCP/4nDi5xD4+Y11BZCKPCMef0pl7apNw+HLo tKwsvdyP+XU1dsHHJ/80Q43rvnbCCi97MDySgiqZ/0WtzNYBH57zZzP4g0XzzRznxXye rsC/eNd6fssEz2mThT3ipuBdkYutc6JMh6Bl3RvzNRLgOX8hJ73dHj51pFyjqG1XOi9a CVxSTLcoHpVtgu0P+W1Z3N8Szf3BzrU5bQCR3mICjF3b2ueY6SCnN9faY4oDP7lTHsKN uE2Q==
X-Gm-Message-State: APjAAAWE6gSkr0lIoymWGlYp0cHCBHQw2zU1894RyOamICmly+Pvm8KL QE/OQUsy//9l/5gu2hMvU6E9rf6iPNg8OexpNB8=
X-Google-Smtp-Source: APXvYqzJgYMQitOk20Nq91BsM25nmTm1bjpB9hT59XmUrNEQcA7dBEJ8znRjSTBPvZkaciXGpg45gv+4vScY8u72XFw=
X-Received: by 2002:aa7:9688:: with SMTP id f8mr11071921pfk.77.1567785363014; Fri, 06 Sep 2019 08:56:03 -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> <BYAPR05MB5463E9041AB1A10A46E2A9FAAEBA0@BYAPR05MB5463.namprd05.prod.outlook.com>
In-Reply-To: <BYAPR05MB5463E9041AB1A10A46E2A9FAAEBA0@BYAPR05MB5463.namprd05.prod.outlook.com>
From: Robert Raszuk <rraszuk@gmail.com>
Date: Fri, 6 Sep 2019 17:55:47 +0200
Message-ID: <CA+b+ER=QbU+-+oKnif+-6dWbbW9eiX6SFP0XNvNuVT=s0KdYDQ@mail.gmail.com>
To: Ron Bonica <rbonica@juniper.net>
Cc: "Darren Dukes (ddukes)" <ddukes@cisco.com>, Fernando Gont <fgont@si6networks.com>, "spring@ietf.org" <spring@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a589450591e47917"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/NePCNtQzpskS30DITTqaS0D4sk4>
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 15:56:07 -0000

Well the term "*shut* *down"* is not precise here. IETF can not shut any
work .. you can keep working on anything you like and keep submitting
individual drafts for it. If you are nice to an AD he me even sponsor it
for publication.

SPRING WG however already has spectrum of mature solutions which address
the problem space - so adopting new proposal now would be more of
distraction then anything else. Also note that SPRING WG adoption will have
an avalanche effect as number of WGs are waiting for SPRING to consider
SRv6+ related drafts to be adopted or not.

Thank you,
R.


On Fri, Sep 6, 2019 at 5:47 PM Ron Bonica <rbonica@juniper.net> wrote:

> Robert,
>
>
>
> Your comment about killing innovation in the IETF strikes me as being odd.
> I never recommended shutting down SRv6 work. In fact, I support it.
>
>
>
> It is you who are asking to shut down SRv6+ work.
>
>
>
> So, who is looking to kill innovation in the IETF?
>
>
>
>                                                      Ron
>
>
>
>
>
> *From:* Robert Raszuk <rraszuk@gmail.com>
> *Sent:* Friday, September 6, 2019 4:18 AM
> *To:* Ron Bonica <rbonica@juniper.net>
> *Cc:* Darren Dukes (ddukes) <ddukes@cisco.com>om>; Fernando Gont <
> fgont@si6networks.com>gt;; 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.
>
>
>
>
>
> Juniper Business Use Only
>