Re: [lisp] [spring] IPv6-compressed-routing-header-crh

Robert Raszuk <robert@raszuk.net> Fri, 12 April 2019 22:13 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 72C09120222 for <lisp@ietfa.amsl.com>; Fri, 12 Apr 2019 15:13:18 -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_PASS=-0.001, URIBL_BLOCKED=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 L15JrhfXIwAz for <lisp@ietfa.amsl.com>; Fri, 12 Apr 2019 15:13:15 -0700 (PDT)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 020E1120153 for <lisp@ietf.org>; Fri, 12 Apr 2019 15:13:14 -0700 (PDT)
Received: by mail-qt1-x844.google.com with SMTP id p20so13026472qtc.9 for <lisp@ietf.org>; Fri, 12 Apr 2019 15:13:14 -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=2fS0ON8kaiWudWg7vve7pxDdwWA26K2xrSxjKNGWg9w=; b=QABvau4fNK2d0vEqzZ54DL5zz8ryWJ6OORefhk7ernYpBrkuzkjRbUQvubSNZBQ8tx domTomFPCNO1EGnc9BUKYrdCAzRuXye0yj5JneQOaSBbiF8x5MdRmcS2e+Pqu1avkgaK fFU9FvdonlQYFjLJCEhW+4rbW+WcxWgQ32vkUD1mz6rEz2LmjInGq079Y41c5EJde1DO k+SPRGe/zmodVq385rI2rU8qpx4JaoHE0En5+fxRuEYWjj1yD56GkS6PUBnyzu8vQqfl 3iVYVJnzqi7lO/HrusETD14dxCgImfwm9OXqxu0Oy2LajpoOjPscoNDFQqJ7kSuny3Yj 5xdQ==
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=2fS0ON8kaiWudWg7vve7pxDdwWA26K2xrSxjKNGWg9w=; b=JBHTc4WVnyUtgevPzTGBDvawu0B3GDgq/LJ1gUO6pfhlW6beO88xHrX77SrXpgpRzZ VFItROOhw03B/TUh+obyA0QS71f6aF6pPceUbnEPytnzdoEsyhenw8/vM6ZK0uz6Ae2b tmhUzU8dShu3Hgt+11q832+DETKwvDXGtVhCmLJ87s5neIfgbVwwb1YMdX0eTwMgaXRE CNEPm7rUFDNuAz+/CqRfjn1CfV829tGkG82FsWk2O5xuOuDL3cVDZqIDwJxmg3gXE4Ol CpUk85XPMAgCrxQfwCPD3gY89KdG0KoZOM+X1m8oZDTLP3gs4XoLIJXZmbLbKPgDrHl1 L1CQ==
X-Gm-Message-State: APjAAAX7ZQlj7Hg7HF1AJ0w9quypJELJrnvYMmIjiOqiOxDreTa+PIg1 0x1BXjUlLcSu4m0GPMHFJl2pnuEUmCQ8W3wKrxTE3A==
X-Google-Smtp-Source: APXvYqzq0RMAqky4X0q0VmY+CyT894sOqVBjsEDAEJCtGxQwtKItqhsWYrXwW/FqTP+WUvJucHC+LkCjg1kgdTnCbJ8=
X-Received: by 2002:a0c:b095:: with SMTP id o21mr47372292qvc.162.1555107193998; Fri, 12 Apr 2019 15:13:13 -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> <CAOj+MMHXWsXbBmByy8TWNfAWm0fKuiN6BDdGLzBgN7GRHkz+1A@mail.gmail.com> <CALx6S34FPPq9R=RAxhnPJRHT8z07htnC8banLkL2gU94Bz61hQ@mail.gmail.com> <CAO42Z2z+4JhObAktyd0KrULdwcrSkiFOD4cOVPt0QeVdHVES9A@mail.gmail.com> <CALx6S35Xnymc3oSKOX68bmtuWTH_6_Cd10FwjOd0db9TXVGp8Q@mail.gmail.com>
In-Reply-To: <CALx6S35Xnymc3oSKOX68bmtuWTH_6_Cd10FwjOd0db9TXVGp8Q@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 13 Apr 2019 00:13:03 +0200
Message-ID: <CAOj+MMG79BeMy2HgeS0WFs8+ZZzpNG77M8E7A4zbDjjKs7wG3Q@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
Cc: Mark Smith <markzzzsmith@gmail.com>, "ipv6@ietf.org" <ipv6@ietf.org>, SPRING WG <spring@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>, Dino Farinacci <farinacci@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000e2e32a05865c9b21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/9xQYDKQF4FoNX5RQZgyXx2YV91E>
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: Fri, 12 Apr 2019 22:13:18 -0000

Hi Tom,

I already suggested this on March 30th ...

*"PS. But if you choose to go ahead with CRH I would highly advise to make
your CRH SID a variable length. "*

No feedback/response was received from authors.

Thx,
R.

On Sat, Apr 13, 2019 at 12:09 AM Tom Herbert <tom@herbertland.com> wrote:

> On Fri, Apr 12, 2019 at 1:48 PM Mark Smith <markzzzsmith@gmail.com> wrote:
> >
> > Hi Tom,
> >
> > On Sat, 13 Apr 2019 at 00:26, Tom Herbert <tom@herbertland.com> wrote:
> > >
> > > On Sun, Mar 31, 2019 at 7:40 AM Robert Raszuk <robert@raszuk.net>
> wrote:
> > > >
> > > > 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 ?
> > > >
> > > Robert,
> > >
> > > I don't see in the SRH draft where 32 bit SIDs are defined. Can you
> > > please provide a reference?
> > >
> >
> > To clarify, I've been thinking about the idea of a smaller SID size
> > for IPv6 for a while now (since inserting EHs came up), and thought
> > about what would be a generic single size that might suit SR that
> > wasn't the same size as an IPv6 address. 32 bits seemed suitable to
> > me, although if people wanted bigger, I'd be suggesting 64 bits (not
> > entirely coincidentally the common IID size.)
> >
> > Ron and others have written this draft, which supports SIDS of various
> > sizes - 8, 16 or 32 bits - that triggered this discussion.
> >
> Mark,
>
> Why not just put a SID length field in the header (like RFC6554 but
> more generic). That would allow lengths of 1-16 bytes. Additional
> flags could be used to indicate the semantics of the entries. For
> instance, they might be actual addresses (128 bits for IPv6, 32 bits
> for IPv4), parts of addresses (prefixes of suffixes like in RFC6554)
> where the rest of the address can be inferred, indices into a table,
> labels, etc.
>
> Tom
>
> > "The IPv6 Compressed Routing Header (CRH)"
> > https://tools.ietf.org/html/draft-bonica-6man-comp-rtg-hdr-03
> >
> > Regards,
> > Mark.
> >
> >
> > > As for trying to use something that already exists, why does SR used a
> > > fixed size format for SIDs instead of a variable length format like
> > > that described in RFC6554? Similarly, why does SR define it's own TLV
> > > format instead of using Hop-by-Hop and Destination Options defined in
> > > RFC8200?
> > >
> > > Tom
> > >
> > > > 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.
> > > >
> > > > --------------------------------------------------------------------
> > > > IETF IPv6 working group mailing list
> > > > ipv6@ietf.org
> > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > > --------------------------------------------------------------------
>