Re: IPv4 EH proposal
Tom Herbert <tom@herbertland.com> Fri, 13 September 2019 20:10 UTC
Return-Path: <tom@herbertland.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 2959412084C for <ipv6@ietfa.amsl.com>; Fri, 13 Sep 2019 13:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.20150623.gappssmtp.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 utiTYOjyyfyW for <ipv6@ietfa.amsl.com>; Fri, 13 Sep 2019 13:10:45 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 B4EA312013A for <ipv6@ietf.org>; Fri, 13 Sep 2019 13:10:44 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id y91so28061237ede.9 for <ipv6@ietf.org>; Fri, 13 Sep 2019 13:10:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pYrzYebyoPAmWkVK8n0Xzr+iV3srGos0gUfEf1pRZdY=; b=GyCcGfxpmApHM5Br1tSowf0LKRaKAzCIIYR04b3iGM434P2DyW3dqHU+Eg73lJN8wq y33P6YpYxYAEqTnOZAqqqIU1zkhl8tEBmidnXutBLsQwRUHu0KxAkp05X1J1/W4RhK3a GOjWXo9+johMB+0Cj7DWmCfWOyl71TfLGJqxmHIxbMk+1pgeB30C9OEE+1NJisVrMAQt 4Pc72EO9WEMEocY8mjpwD6/pq7eNC4HSzuikbgLtMiWLdXtZyV03MzyPANreZIMo3cR4 5WTtNAMcSWGPuUhTod1my+mnbjdbulUDFbYkYHH7onvPihWrK+7yomY+kBZFotC+8q5U 5DLQ==
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:content-transfer-encoding; bh=pYrzYebyoPAmWkVK8n0Xzr+iV3srGos0gUfEf1pRZdY=; b=UXlW+/0qlT4qdq125qMON3vZslLmGOAA63wEpvCIbnYxc9OhW5BCv7NXzbxpvPMFUE nzFXInu6YM3xlznJd8uoloBJeey2/tRCzgh5RN9qZxvTTTb34Be+YPy3gXHGbS1UN91J XfHpb2lyHkJI0ZugSyZNOXhTsfcx54kzwYnXw2JwjeEkxUTN6iUCDySjHFKAurNFUEcO 5ZAfYraqJrYjJ+Jx6AK9WQAl4CbLFTedFDkHbjbBlt6fdiwn0zd1kU17zUaJm3xJ3mPK awZ2Rzrs1YIn365+HHqs7jprQJ1YvtuClaPx92tj46Sj1u8pluuvz64GLfM7Hjn990I3 dPHg==
X-Gm-Message-State: APjAAAXx5cg8/sHyKgPsF76JV0Z96bemeHwE0fGCmeWERT4qk5BU5Mfe Z3feZUW9A3Blbbt8X0p9IIiv/pfP+2iJcQSHPmTcf+sZWVU=
X-Google-Smtp-Source: APXvYqyIlNFS3oNyKJk9helVjmXgXvLPzH2AwVmJ1tiFHRBg3gXHK74bRz9hpiBeE//oOuC8GhH420vf/S1JPAWnUL0=
X-Received: by 2002:a17:906:3446:: with SMTP id d6mr10283246ejb.244.1568405443146; Fri, 13 Sep 2019 13:10:43 -0700 (PDT)
MIME-Version: 1.0
References: <BYAPR05MB5463153B47BFE83350C566E7AEBA0@BYAPR05MB5463.namprd05.prod.outlook.com> <CA+b+ERm4x072JQZQovX0MVcea3=0DOCSESopAXj_SE1vMi8qkQ@mail.gmail.com> <06CF729DA0D6854E8C1E5121AC3330DFAE9362F9@dggemm529-mbs.china.huawei.com> <CAO42Z2y-hq71wr9ogzmn2=rO0xySy63iXhNXrFDuqO7r5Pwa7A@mail.gmail.com> <CAOj+MMFN5pbaVePWrJA61jd7f9d_2bU-Nu9oppFDsAc_B7APDw@mail.gmail.com> <CAO42Z2x4-9-1YseuyqnCRh7c+J-zb2ksGXpk_Hs17H5uLz4Hvg@mail.gmail.com> <CAOj+MMHHMdGm6Qea4E1ugQBrSYFr7e-FgP+pxoErhEwRR9GwKw@mail.gmail.com> <e31311de-6db5-8172-fbdd-11b461a330c8@asgard.org> <daeebebe-65a2-c499-5112-058f3ab46fda@gmail.com> <C6D92088-97F3-4633-AC2C-E07411C879F1@gmail.com>
In-Reply-To: <C6D92088-97F3-4633-AC2C-E07411C879F1@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 13 Sep 2019 13:10:31 -0700
Message-ID: <CALx6S34sAQ-3Fak3uhvT5VFwk3UfJ9-MH1SisFEc=9K8Reas-A@mail.gmail.com>
Subject: Re: IPv4 EH proposal
To: Fred Baker <fredbaker.ietf@gmail.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Lee Howard <lee@asgard.org>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/gMHtequ_6RLAxWZhSHqWF5NafzY>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 13 Sep 2019 20:10:50 -0000
On Fri, Sep 13, 2019 at 12:35 PM Fred Baker <fredbaker.ietf@gmail.com> wrote: > > The funny thing, in my mind, is that I agree with both of you. > > I guess at least part of the question is "what does it mean to maintain IPv4?" If it means creating something that is not backwards-compatible with existing-and-deployed IPv4, such as an IPv4 Extension Header, then we're not "fixing" IPv4, we are creating yet another new protocol which we will then somehow need to put to death. If, on the other hand, it can be put into an option that a node can skip if it doesn't understand it, I don't think that is going to hurt IPv6 deployment any more than bone-headed "there is just no **** way I'm going to deploy IPv6" does. The latter is what I see in a lot of enterprise deployments. > Fred, That's well said. The problem I see is that the answer to just move to IPv6 seems to assumed an idealized reality that doesn't exist. If we can't improve IPv4 then people will find other ways to achieve the necessary functionality (similar to how NAT was created?). A specific example relating to extension headers is the proposal to hack up GRE to effectively implement extension headers in an EtherType (draft-weis-ippm-ioam-eth-02). I'm pretty sure everyone will agree that this is a stunning hack and a complete abuse of EtherTypes, but nevertheless it does seem to be plausible as solution for IOAM in IPv4. I find it hard to believe that accepting a hack like this is a good tradeoff for upholding the letter of the law. I will be posting an update to the IPv4 EH draft shortly (to int-area list). This will significantly narrow the immediate use cases and is much less ambitious (this will only enable HBH and DO in IPv4). The concept of using SR EH in IPv4 will be out of scope for that draft, but presumably many of the principles could apply. Tom > > On Sep 9, 2019, at 9:35 PM, Stewart Bryant <stewart.bryant@gmail.com> wrote: > > > > Without commenting on the specific technical proposal. > > > > IPv4 is still critical infrastructure in many organizations. > > > > We have to maintain it until its natural death. If we neglect the maintenance, or worse try to euthanise it, it will end up either explicitly or implicitly being maintained by another organization. > > > > We would thus be wise to actively maintain IPv4 for as long as users need us to, rather than to risk loosing control of it and its future developments. > > > > - Stewart > > > > > > On 07/09/2019 16:01, Lee Howard wrote: > >> IPv4 is dying. Let it go gracefully. > >> I'm completely opposed to any extensions to the IPv4 specification. By the time the feature set is code complpete, QA'd, and ready for general release, 80% of the world will be using IPv6. > >> Specific to this case, I have a very hard time understanding the business/engineering case where it would be optimal to implement these extensions rather than deploy IPv6, where they already exist. > >> Lee > >> On 9/7/19 7:32 AM, Robert Raszuk wrote: > >>> /* Adjusting the subject to reflect the topic */ > >>> > >>> Ok ... I looked at the new wave of mails in wrong order :) > >>> > >>> I like this proposal: > >>> > >>> https://tools.ietf.org/html/draft-herbert-ipv4-eh-01 > >>> > >>> And have absolutely nothing against progressing it further - it looks on the surface to be more efficient then sr-mpls over IP - but how many bits are we saving needs to be calculated to state if cost of introducing new encoding justifies the additional control plane, protocol and platform efforts > >>> > >>> In fact if we would get to the consensus of using SRH with SID & BSID to be of fixed 20 bits it can reuse a lot of mechanism build for sr-mpls in any commercial router. > >>> > >>> It is just a bit amazing that insertion of EHs into IPv4 would be less problematic that in the case of IPv6 :) Maybe due to allowed fragmentation. > >>> > >>> As to the host dropping packets due to unknown protocol - let's observe that SR domain would clean such EH before passing packets further. > >>> > >>> Many thx, > >>> R. > >>> > >>> > >>> > >>> On Sat, Sep 7, 2019 at 1:14 PM Mark Smith <markzzzsmith@gmail.com<mailto:markzzzsmith@gmail.com>> wrote: > >>> > >>> On Sat, 7 Sep 2019 at 19:56, Robert Raszuk <robert@raszuk.net > >>> <mailto:robert@raszuk.net>> wrote: > >>> > > >>> > > It's tempting to write up SR over IPv4 > >>> > > >>> > You don't have to write anything ... it is already written and > >>> looks like moving fwd :) > >>> > > >>> > https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07 > >>> > > >>> > >>> That's tunnelling MPLS over SR over IPv4. I'm talking about native SR > >>> over IPv4 e.g. "SRv4". > >>> > >>> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests:https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- Regaining Focus on SRv6 and SRv6+ Ron Bonica
- Re: Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Tarek Saad
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Tarek Saad
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Huzhibo
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Mark Smith
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Huzhibo
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Mark Smith
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Huzhibo
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Mark Smith
- IPv4 EH proposal Robert Raszuk
- Re: IPv4 EH proposal Nick Hilliard
- Re: IPv4 EH proposal Robert Raszuk
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Zafar Ali (zali)
- Re: IPv4 EH proposal Lee Howard
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Xiejingrong
- Re: IPv4 EH proposal Tom Herbert
- Re: Regaining Focus on SRv6 and SRv6+ Tom Herbert
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Gyan Mishra
- Re: IPv4 EH proposal Bob Hinden
- Re: IPv4 EH proposal Bob Hinden
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Tom Herbert
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Ron Bonica
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Ron Bonica
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Ron Bonica
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- Re: [spring] Regaining Focus on SRv6 and SRv6+ - … Joel M. Halpern
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Xiejingrong
- Re: IPv4 EH proposal Alexandre Petrescu
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Chengli (Cheng Li)
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- RE: [spring] Regaining Focus on SRv6 and SRv6+ Chengli (Cheng Li)
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Tom Herbert
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Robert Raszuk
- RE: [spring] Regaining Focus on SRv6 and SRv6+ - … Ron Bonica
- Re: IPv4 EH proposal Stewart Bryant
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Fernando Gont
- Re: IPv4 EH proposal Fernando Gont
- Re: [spring] Regaining Focus on SRv6 and SRv6+ Tom Herbert
- Re: IPv4 EH proposal Fred Baker
- Re: IPv4 EH proposal Tom Herbert