Re: [lisp] [spring] IPv6-compressed-routing-header-crh
Robert Raszuk <robert@raszuk.net> Sun, 31 March 2019 14:40 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F53120185 for <lisp@ietfa.amsl.com>; Sun, 31 Mar 2019 07:40:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_PASS=-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 sPZYsq337xpX for <lisp@ietfa.amsl.com>; Sun, 31 Mar 2019 07:40:01 -0700 (PDT)
Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 77D3912014F for <lisp@ietf.org>; Sun, 31 Mar 2019 07:40:01 -0700 (PDT)
Received: by mail-qt1-x82a.google.com with SMTP id t28so7923015qte.6 for <lisp@ietf.org>; Sun, 31 Mar 2019 07:40:01 -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=NSneUUHlL5tGzr249jAhwr08ze+Qw65tRAnbZJEqLY8=; b=aCpu29OkFDYLXzw1qTqWuvTSjrmHWSLJr9/dDHLsQIsYOZ7YkV/AKQ8ewlaIT9+o/K ZFw9JLRLUbFUFUELjjOgqyyFX0qjQjoPBig868ZbufWjIqr/8u5z84X4ZUHTm47WHITu eDXboA28gUN5Z5nJFsWh6rXmFRpbiuyHMH4juCLnBUbS+vMMGhA1iQQ3PScsEe4e644v 2pUTl/B0sLTQekcNeP0x3ZERkH5SG69GE6I76Huzj/k9kUNS6XEDl+NtajnwcFfqWYOe JwkB9SoOSAkZsy+DOtv/XOD+W2OGQSFJ/gW7Mu1STG7tq6OudhbFHZg5w3TUm/CRz1C+ tthw==
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=NSneUUHlL5tGzr249jAhwr08ze+Qw65tRAnbZJEqLY8=; b=liQccFFg9ueZJtGvbJJpWxMeQZCkHZ1wzI/OavdPOWoGRYqlqEKxAk9dbRdVY2hJvi 2MrSLVOjZMzpyD6+hgXBVGYr3rHjt8aOuUnJJtme6YVyNx9G19zAmL4GC2dGdDaNAGtM I0bcoGOxA6d573bpiCNT43upaRFwim7NaFN2Hm16gO8dxwiIMyBdlfnHl7Pyl4HiokKr h+41b6x5vxSsJmU/cj2bXCEmFUUXLx8OvDnCVQjozHaHL4rEBmMQA2UHXv2Rye5SDg0Z GswnPMFSkejCaAZ0Zp+j5GqOat6JfelgxRgqT7m12Dfr/vRNFI2N++jsnSCpRxJ2XTS3 U8sw==
X-Gm-Message-State: APjAAAUAZnpK+XA/7yr6azA+uymWs0XbpnhQDf6li2M61oXXPGlLKM+S 2B/2zq13ccICTC5Vmh2vO6VDHvzigHr60ACnaetnhw==
X-Google-Smtp-Source: APXvYqyCswT9gZKJb44W7QFB4Dd2tWntVCogGDw3OjHMBUcnmipMlUHyGgCpY+JDkmmsF5ebhgVkhe+7V63+1+/HHTw=
X-Received: by 2002:a0c:aee6:: with SMTP id n38mr46855950qvd.69.1554043200266; Sun, 31 Mar 2019 07:40:00 -0700 (PDT)
MIME-Version: 1.0
References: <A881B89B-5E72-40CD-81F3-50396958A554@cisco.com> <BYAPR05MB4245D3F821D84847549FB6DAAE5A0@BYAPR05MB4245.namprd05.prod.outlook.com> <CA+b+ERmo9cPgCtnDgvkqNkFiLXdOJikWRLOKXM9NQfbNtJ__Zg@mail.gmail.com> <CAO42Z2yKmWub+maw4oVzaEY4HoHVszwOo4FQNCHT0uVkKFNwRw@mail.gmail.com> <CA+b+ERk+UiXg5Vtv-2kshkJ9VQMpMF22deFpKfGeMmqbBE9QtA@mail.gmail.com> <CAO42Z2yPi6wb85jh5es3feboJ5fOhr+iS8OraPjLD-rKTkNSQg@mail.gmail.com>
In-Reply-To: <CAO42Z2yPi6wb85jh5es3feboJ5fOhr+iS8OraPjLD-rKTkNSQg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 31 Mar 2019 16:39:49 +0200
Message-ID: <CAOj+MMHXWsXbBmByy8TWNfAWm0fKuiN6BDdGLzBgN7GRHkz+1A@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Robert Raszuk <rraszuk@gmail.com>, SPRING WG <spring@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Dino Farinacci <farinacci@gmail.com>, lisp@ietf.org
Content-Type: multipart/alternative; boundary="000000000000eaf781058564e01e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/mDAZifTXqQqlC4WU5Nv8wcMQsOA>
Subject: Re: [lisp] [spring] IPv6-compressed-routing-header-crh
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 31 Mar 2019 14:40:05 -0000
Hi Mark, > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a 32 bit alignment, > I'd think 32 bit SIDs would be adequate to perform SR in an IPv6 network. > > As 32 bit SIDs are also the same size as IPv4 addresses, that may also create some opportunities to > leverage IPv4 support in existing protocols to suite carrying and processing 32 bit SIDs with some, possibly > slight, modification. For example, perhaps IPv4 Address Family support in OSPFv3 (RFC 5838) could be > somehow leveraged to suit SR. Thank you for describing your understanding of fundamentals of SR. I think SR while indeed started with the story of "less control plane is good for you" now clearly has evolved into not only reduction of control plane but what can be even more important to some users ability to request specific behavior via programmed functions of network elements on a per flow basis without actually per flow or per path signalling or state. Yes for some it may be very useful feature and I am sure some will call it overload of data plane or . There is no one size fits all. With that let's observe that till today SR did not require any new mapping plane to be distributed in control plane and to be inserted into data plane. This is clearly a precedent. Furthermore as we see in companion documents all additional network functionality is being taken away from SRH and is being shifted to Destination Options . As far as mapping plane I already pointed out in my Vector Routing proposal that we have one already it is called BGP. One needs to also observe that we as industry worked number of years of protocol suite called LISP allowing not only very good mapping plane, but also data plane integration. CC-ing lisp authors for their comments. Note also work for integrating SRv6 with LISP which is already is published. Since you correctly observed that now SID can be 32 bit and that is similar to the size of IPv4 my fundamental question is why not use something which already exists instead of defining some sort of new from scratch ? It will be perfectly fine to have full proper SRv6 with SRH and LISP or Vector Routing as an alternative options. I really do not see a room or need for yet one more mapping plane. What problem does it solve which would not be already solved elsewhere ? Kind regards, Robert 2) Is there an agreement that solutions which require additional per SR >> path state in both control plane and now in data plane are really something >> we should be endorsing here ? >> > > I think so. > > My understanding of what SR is fundamentally about is to reduce control > plane state and processing. The trade-off for reduced control plane state > and processing is to instead carry and encode most or all of that > information or its semantics as per-packet overhead. > > If the per-packet overhead becomes too large and expensive, then pushing > some of that information and processing back into the control plane should > be ok, as long as there is still a beneficial overall reduction in control > plane state and processing. > > As MPLS SR SIDs are 20 bits, then rounding up to an octet boundary and a > 32 bit alignment, I'd think 32 bit SIDs would be adequate to perform SR in > an IPv6 network. > > As 32 bit SIDs are also the same size as IPv4 addresses, that may also > create some opportunities to leverage IPv4 support in existing protocols to > suite carrying and processing 32 bit SIDs with some, possibly slight, > modification. For example, perhaps IPv4 Address Family support in OSPFv3 > (RFC 5838) could be somehow leveraged to suit SR. > > Regards, > Mark. >
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Robert Raszuk
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Dino Farinacci
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Mark Smith
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Dino Farinacci
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Tom Herbert
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Ron Bonica
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Dino Farinacci
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Mark Smith
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Tom Herbert
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Robert Raszuk
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Mark Smith
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Ron Bonica
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Gyan Mishra
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Tom Herbert
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Ron Bonica
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Robert Raszuk
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Ron Bonica
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Robert Raszuk
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Tom Herbert
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Robert Raszuk
- Re: [lisp] [spring] IPv6-compressed-routing-heade… James N Guichard
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Dino Farinacci
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Ron Bonica
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Robert Raszuk
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Robert Raszuk
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Greg Mirsky
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Gyan Mishra
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Tom Herbert
- Re: [lisp] [spring] IPv6-compressed-routing-heade… Greg Mirsky