Re: [spring] Beyond SRv6.
Robert Raszuk <robert@raszuk.net> Thu, 12 September 2019 23:15 UTC
Return-Path: <robert@raszuk.net>
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 9962B120058 for <ipv6@ietfa.amsl.com>; Thu, 12 Sep 2019 16:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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] autolearn=unavailable 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 ZFYk5hXOTTLR for <ipv6@ietfa.amsl.com>; Thu, 12 Sep 2019 16:15:23 -0700 (PDT)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 7EC0F12002E for <6man@ietf.org>; Thu, 12 Sep 2019 16:15:23 -0700 (PDT)
Received: by mail-qk1-x72c.google.com with SMTP id 4so26263455qki.6 for <6man@ietf.org>; Thu, 12 Sep 2019 16:15:23 -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=1Cfu90XQSXxMZ02G5u88A7bSF6qdvHdClyg1XCBeg9c=; b=D7qDhRcSxiNR9IjdS0U9x59Yrn8i3eJcfrRu/ohvTCaV8iojfMtgEvyDmgA9TiH1mE UtjlzMuwzFo2W9Y27o/blROdQ7lRghrRa7X9Z7gEQhpuBOwMl2g96nXhs4XFMej4HLKD 8Rbi/d6ng+W/n19kD31uRQfGm1Hy9JOcUmqHKf7tNWS9auNxOYx6309eYTHC5nrn//Te EvLYCtRq8EM3WUMuH9Ou4VNk3K9FYMsgh4Ux0hoOtHVYJTK3mqZvR8KUumYZR9BuAY5A HJUY3JWpl5tzBHht3DbFg3uG1JT4l3J45T5kHJPdrxghgfgzfCvYIJxeUF3pDA0y7eDE QT+Q==
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=1Cfu90XQSXxMZ02G5u88A7bSF6qdvHdClyg1XCBeg9c=; b=Lo94/3cJzbmcZ58eD+RUHTMEq7JmnPuQsVnF86X2yeMia+6KpmqJFXb/yiwL6zZNDL KC4WtbYgAgAzfAHmkaINaPh7hLtxztpkZVvPzYbbv+Ag7YUpHA/UDGrx8Kz8Zt3gwfCC FAdc1uG9EzQHSVHWiOifN7Kw66bV8sG6tel49+fDjiRsTFR6j5lQ7rFoF2/gqBUJPTOX pn8BjqyjDhT1Ah4NnYO8mKgPWaTudtG0vMAc35mvme35kZ2lZDvoKHF51PkAGHWU4z+J 06jjSxiELGxlUgSKCQPrBzudDE0cGGm+/8TJwFlQlzvYmf6fXkKHmETgeFyJ+3bXrlxQ k2WQ==
X-Gm-Message-State: APjAAAU6Fo+pBkpapkM3k3cC2qWVSzRTS9Ue1F5CHbnybkokHt/tNb5m vLX5sxq0UmL26hG1McSwHhqAnTO0Ae3y2T0Ml0HNNQ==
X-Google-Smtp-Source: APXvYqxCtpGTeXOwpjiI3i5DhBPsb9S4YLtXE6tbVAM/0uA6/7GgQCq08OZBoUJ+cuh+MNVCAlbtD6TzNPzd0pFuDt4=
X-Received: by 2002:a37:6144:: with SMTP id v65mr42516201qkb.465.1568330122294; Thu, 12 Sep 2019 16:15:22 -0700 (PDT)
MIME-Version: 1.0
References: <5B57874F-8C54-4E82-BB55-A2B6585B6AE6@bell.ca> <BYAPR05MB5463BA9F2C38745F4BDF5C28AEB00@BYAPR05MB5463.namprd05.prod.outlook.com> <CAOj+MMHvc-P=j0dvs0uMS+NmapQ-RbcgzC4OLg5evUjYpcaoQQ@mail.gmail.com> <704dbd1e-b1e6-0924-42b1-6bf19fa785fe@gmail.com>
In-Reply-To: <704dbd1e-b1e6-0924-42b1-6bf19fa785fe@gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 13 Sep 2019 01:15:12 +0200
Message-ID: <CAOj+MMExK2hkex0SiMPZf-XtXstSoibBWSrmXqtazjCS6xUS-A@mail.gmail.com>
Subject: Re: [spring] Beyond SRv6.
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Ron Bonica <rbonica@juniper.net>, "xiechf@chinatelecom.cn" <xiechf@chinatelecom.cn>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, Rob Shakir <robjs@google.com>, Tarek Saad <tsaad.net@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000d48aa80592634f0b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ztZIoax6zLli975o7KMyR7XDW6k>
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: Thu, 12 Sep 2019 23:15:27 -0000
Hi Brian, > To what extent is this behind the present argument? If you are calling elephant and ASIC/FPGA - that was not my reasoning at all. Regardless if you are processing packets by a fixed burned ASIC or programmable NP the packet must be read into DRAM and its header stored in SRAM during processing - that is I hope pretty clear to everyone. What matters is the amount of SRAM you have at your disposal and then how far apart are elements required for processing a given feature. I am full supporter of NPs and actually just fyi in my MS thesis I designed and prototyped Altera MAX FPGA based router :). If one can afford for required line rate speed rating and total box throughput using NP based systems is much better investment. This is more for flexibility (field programmability) and software updates for bug fixes and new features then anything to do how we should or should not design the packet headers in data plane protocols. In the comment below I was not really making an observation that when you separate multiple DOHs from CRH you can not process things - you sure can as all such EHs actually carry opaque to each other elements. I was however observing the fact that functions may require parameters which are not supported by DOHs as well as observed earlier that if you are to make sure packets entering your domain or leaving "escaping" your domain contain any unexpected headers it is much easier to set such ACL onces instead of keep updating it every time new draft gets published and new type gets allocated for another SRv6+ Destination Option. Many thx, Robert On Fri, Sep 13, 2019 at 12:32 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Robert, > > > But what is most important that common hardware reads just entire > > header then starts processing. So it really makes much more sense to > > encode SR SIDs and related functions and their parameters in the same > > EH rather then scatter them around. > > Sorry to get all philosophical, but it seems to me that there's another > elephant in the room here (and he's been around for twenty years or so). > There seems to be an assumption that we should design on the assumption > that fast path processing is done by ASICs or FPGAs, so header formats > should be rigid enough that conditional or linked-list processing can > be largely avoided. I've been lectured on the bad design of IPv6 extension > headers in a way that only makes sense from an ASIC or FPGA viewpoint. > > But anybody who's building the fast path using a network processor doesn't > have that constraint and can use the existing extension header design > happily enough. > > To what extent is this behind the present argument? > > Regards > Brian Carpenter
- Fwd: [spring] Beyond SRv6. Gyan Mishra
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Tom Herbert
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Andrew Alston
- RE: [spring] Beyond SRv6. Parag Kaneriya
- RE: [spring] Beyond SRv6. Shraddha Hegde
- Re: [spring] Beyond SRv6. Fernando Gont
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Tarek Saad
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Nick Hilliard
- Re: [spring] Beyond SRv6. Reji Thomas
- Re: [spring] Beyond SRv6. Sander Steffann
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- Re: [spring] Beyond SRv6. sthaug
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Zafar Ali (zali)
- RE: [spring] Beyond SRv6. Andrew Alston
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Tarek Saad
- Re: [spring] Beyond SRv6. Srihari Sangli
- Re: [spring] Beyond SRv6. Ca By
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Gyan Mishra
- 答复: [spring] Beyond SRv6.(CCDR Proposal) Aijun Wang
- Re: [spring] Beyond SRv6. 松嶋聡
- Re: [spring] Beyond SRv6. Dirk Steinberg
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Andy Smith (andsmit)
- RE: [spring] Beyond SRv6. Shraddha Hegde
- Re: [spring] Beyond SRv6 Alexandre Petrescu
- RE: [spring] Beyond SRv6 Ron Bonica
- Re: [spring] Beyond SRv6 Satoru Matsushima
- Re: [spring] Beyond SRv6. =?utf-8?B?SGlyb2Z1bWkgSWNoaWhhcmE=?=
- Re: [spring] Beyond SRv6. Satoru Matsushima
- Re: [spring] Beyond SRv6. =?utf-8?B?SGlyb2Z1bWkgSWNoaWhhcmE=?=
- Re: Re: [spring] Beyond SRv6. xiechf@chinatelecom.cn
- Re: Re: [spring] Beyond SRv6. Tom Herbert
- RE: [spring] Beyond SRv6. Bernier, Daniel
- RE: [spring] Beyond SRv6. Xiejingrong
- Re: [spring] Beyond SRv6. Mark Smith
- Re: [spring] Beyond SRv6. Tom Herbert
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Ron Bonica
- RE: [spring] Beyond SRv6. Bernier, Daniel
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Robert Raszuk
- Re: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Brian E Carpenter
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Ron Bonica
- Re: [spring] Beyond SRv6. Tom Herbert
- Re: [spring] Beyond SRv6. Robert Raszuk
- RE: [spring] Beyond SRv6. Xiejingrong
- RE: [spring] Beyond SRv6. Bernier, Daniel
- “SRV6+” complexity in forwarding Darren Dukes (ddukes)
- RE: “SRV6+” complexity in forwarding Ron Bonica
- Re: “SRV6+” complexity in forwarding Andrew Alston
- Re: “SRV6+” complexity in forwarding Darren Dukes (ddukes)
- Re: “SRV6+” complexity in forwarding Tom Herbert
- Re: [spring] “SRV6+” complexity in forwarding Dirk Steinberg
- Re: “SRV6+” complexity in forwarding Gyan Mishra
- Re: “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “SRV6+” complexity in forwarding Gaurav Dawra
- Re: [spring] “SRV6+” complexity in forwarding Tom Herbert
- Re: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: [spring] “SRV6+” complexity in forwarding Mark Smith
- Re: “SRV6+” complexity in forwarding Fred Baker
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Srihari Sangli
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Reji Thomas
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Reji Thomas
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- RE: [spring] “SRV6+” complexity in forwarding Chengli (Cheng Li)
- Re: [spring] “SRV6+” complexity in forwarding Jeff Tantsura
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Stewart Bryant
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- RE: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] “SRV6+” complexity in forwarding Robert Raszuk
- RE: [spring] “SRV6+” complexity in forwarding Ron Bonica
- Re: [spring] =?utf-8?Q?=E2=80=9CSRV6+=E2=80=9D_?=… Jeff Tantsura
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra
- Re: [spring] “SRV6+” complexity in forwarding Gyan Mishra