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

Tom Herbert <tom@herbertland.com> Thu, 18 April 2019 21:30 UTC

Return-Path: <tom@herbertland.com>
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 3565712017E for <lisp@ietfa.amsl.com>; Thu, 18 Apr 2019 14:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable 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 3caFz70Gx-AD for <lisp@ietfa.amsl.com>; Thu, 18 Apr 2019 14:30:15 -0700 (PDT)
Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 AC131120163 for <lisp@ietf.org>; Thu, 18 Apr 2019 14:30:13 -0700 (PDT)
Received: by mail-qk1-x742.google.com with SMTP id g1so2014761qki.5 for <lisp@ietf.org>; Thu, 18 Apr 2019 14:30:13 -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=dB53xf/7m+ClKvNYDoernxO9Ha+p4vW4Tk9X2hjMlfA=; b=SBvcTkiBanJpjN+Qigcn8AjIcXh2ISTet2XA7vHv0Ak5Fyt+VFqnGh8DdyPC5kM1vL IUlbqTzWB/uzlXqoRqsCZBe9bCSmXz8TKxXoI/C0XB9tAED6jkbvdleRxlnOmDVkyMSd V00xHKjxE0Ni7O3CaLWmdcsn6vvRG92cx0jZJ95jxcIt0pqFxQGTkFHf7hvEtd7xIMiS ZltqJ7YWqXq1GZARHvgUc5IMBNHqNIlf8863P1oSFchVH4SrTz5iJIpWWzVCxZp6zQzo NCMQ60L4BFefCk3vVGzMAC3fit0vYu3KMkAitvNjFbDhZH56NNMwVzCvN1P03EEqGu5k dfYw==
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=dB53xf/7m+ClKvNYDoernxO9Ha+p4vW4Tk9X2hjMlfA=; b=OHl1cwa2XhVA6RYSiRHdETopthejj5gFwXD2YydVpkQJKGBYvIak+fskoR3RG4O2yx AfMADxtloilfDgYFq/iAmFiYbTH+li2QINFeGDLAhrQiTE8DuZlYFXzkuBI5Vkjpv5nk 8bvRZWRydWPwzzIeA3FiIgQ6xyWpmelVo9qxUFbu5FWfWwuM6//fD3bDaxmTDk8+1apt 3llZcMe5YxAauf9rgoxa8+4cZU6OxIHhCWD2B222TnvgGhnRr9MYXVRyJh11uT3BAgg+ 5CttrDxEKrdJtjeAVqc86KPi3BjU7kjqatzy2HEP91c3TIK+weKktbvgtuIo7PljRWTq yTAA==
X-Gm-Message-State: APjAAAXlZ+7OGpG8AekRXWR4Ox1pW6x/+IR4EBywYlSv6oi/I1CV36a4 XzlEhRlYMKrEWKkUGpHLSj9f+sBHQ73CX+F9nlY7Ww==
X-Google-Smtp-Source: APXvYqxr6VmksluDv+4BOC/rValaM39qIQ+MCYZeXA4IhUe8YgUT0CiVjpvP1IQbLwdMqyBHvDaZZfkjDMDdLmb5zuo=
X-Received: by 2002:a37:a34a:: with SMTP id m71mr214331qke.323.1555623012476; Thu, 18 Apr 2019 14:30:12 -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> <CAOj+MMG79BeMy2HgeS0WFs8+ZZzpNG77M8E7A4zbDjjKs7wG3Q@mail.gmail.com> <BYAPR05MB4245D2964D8F90A3A76356C0AE2A0@BYAPR05MB4245.namprd05.prod.outlook.com> <46DF565F-9A1A-4247-9A05-DE04396C8F5A@gmail.com> <BYAPR05MB4245A7C3E215FF0028FE9B06AE260@BYAPR05MB4245.namprd05.prod.outlook.com> <CAOj+MMGhU3bJtfQ4QjCeFiFpj+XkEhjnvU0MgO9bhNEvERN7Ew@mail.gmail.com> <BN7PR05MB424378EE1287B03467E2B4CAAE260@BN7PR05MB4243.namprd05.prod.outlook.com> <CAOj+MMFHTUMrmcNuHirnvO100pgtV1n+3HBCASSmx5=f_1ApWQ@mail.gmail.com>
In-Reply-To: <CAOj+MMFHTUMrmcNuHirnvO100pgtV1n+3HBCASSmx5=f_1ApWQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 18 Apr 2019 14:30:00 -0700
Message-ID: <CALx6S378oLyMnTns7VX8J9S4PfD4Lcwr_0__4ctEA=wptYsRuQ@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica@juniper.net>, Gyan Mishra <hayabusagsm@gmail.com>, SPRING WG <spring@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, Dino Farinacci <farinacci@gmail.com>, "lisp@ietf.org list" <lisp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/w7qgESTP7ohTdG8VOcMKTQ6mdps>
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: Thu, 18 Apr 2019 21:30:20 -0000

On Thu, Apr 18, 2019 at 1:56 PM Robert Raszuk <robert@raszuk.net> wrote:
>
> Hi Ron,
>
> > The Compressed Routing Header (CRH) has exactly one function. That is to route a packet for
> > segment to segment along an SR path. Therefore, SIDs contained by the CRH have only one
> > function. That is to steer packets to the next segment.
>
> Indeed and that is precisely where the fundamental problem resides with your proposal.
>
> Let's take a look at RFC8402 - Segment Routing Architecture.
>
> In body of the above RFC we clearly see definition of SID to be either a topological instruction (your draft meets that requirement) or service instruction (your draft fails to meet those requirements)
>
> To illustrate along with just a basic example from RFC8402 of service instruction - different per hop behavior treatment for traversing packets to be embedded into SID.
>
> So if you are only to associate SID with topological instructions you have no way to express transit service instructions so it seems pretty obvious that your proposal does not meet basic SR network programming requirements.
>
> That means that all you can provide is subset of SR Architecture requirements so perhaps to avoid industry confusion your solution should avoid use of SID or SR references. Perhaps as Tom already also observed we should call it MRH Mapped Routing Header instead.

Robert,

I think I was actually making the opposite argument. The routing
entries in CRH are not addresses and not in themselves topological,
they're values that need to be mapped at each hop. They require
interpretation in the context of a shared state and network wide
configuration, so effectively all CRH entries _are_ instructions. The
fact that entries in CRH are defined only to map to addresses seems to
be a deliberate design choice as opposed to a limitation in the
design. But, assuming that one did want to allow SIDs to represent
arbitrary instructions, I still don't understand why you'd need 128
bit numbers for that-- it seems like 32 or 16 bits would be enough.

Tom

>
> Kind regards,
> Robert.
>
> On Thu, Apr 18, 2019 at 10:29 PM Ron Bonica <rbonica@juniper.net> wrote:
>>
>> Robert,
>>
>>
>>
>> The Compressed Routing Header (CRH) has exactly one function. That is to route a packet for segment to segment along an SR path. Therefore, SIDs contained by the CRH have only one function. That is to steer packets to the next segment.
>>
>>
>>
>> Granted, we may want to program a service behavior at a segment endpoint. IPv6 includes a Destination Options header that can be used to convey information segment endpoints and destination options can contain service SIDs. These service SIDs can be as long or short as they need to be. See draft-bonica-6man-vpn-dest-opt for an example.
>>
>>
>>
>>                                                                               Ron
>>
>>
>>
>>
>>
>> Juniper Internal
>>
>> From: Robert Raszuk <robert@raszuk.net>
>> Sent: Thursday, April 18, 2019 10:30 AM
>> To: Ron Bonica <rbonica@juniper.net>
>> Cc: Gyan Mishra <hayabusagsm@gmail.com>; Tom Herbert <tom@herbertland.com>; SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
>> Subject: Re: [spring] IPv6-compressed-routing-header-crh
>>
>>
>>
>> Hi Ron,
>>
>>
>>
>> I must observe that your analysis is incorrect.
>>
>>
>>
>> SIDs are not only used for TE or traffic steering purposes but what is even more interesting for various functions - for example NFV.
>>
>>
>>
>> So you need as much SIDs as possible imagination of your value add network functions - which will be different from those functions at the encap dst which as you indicate in other draft can be carried in destination options.
>>
>>
>>
>> That debate is still I think open.
>>
>>
>>
>> Thx,
>>
>> R.
>>
>>
>>
>>
>>
>> On Thu, Apr 18, 2019 at 4:02 PM Ron Bonica <rbonica@juniper.net> wrote:
>>
>> Gyan,
>>
>>
>>
>> Let’s think about how a network operator might choose a SID size….
>>
>>
>>
>> Assume that an MAN includes 100 routers. These routers are connected to one another by infrastructure links. Each router has 20 or fewer infrastructure links.
>>
>>
>>
>> The network operator might assign one loosely routes SID to each router. These loosely routed SIDs have network-wide significance (i.e., the cannot be reused).
>>
>>
>>
>> The network operator might also assign one strictly routed SID to each link. The strictly routed SIDs have node-local significance only. They can be reused from one node to another.
>>
>>
>>
>> So, in this case, the network operator only needs 120 SIDs. This fits in eight bits with plenty of room for growth.
>>
>>
>>
>> Now consider another network that includes 30,000 routers. Each router is connected to its peers by 200 infrastructure links or fewer.  This network would need 30,200 SIDs. This would fit in 16 bits.
>>
>>
>>
>> A *really big* network might require more than 32,000 SIDs. So, we support a 32-bit SID.
>>
>>
>>
>>                                                                             Ron
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Juniper Internal
>>
>> From: Gyan Mishra <hayabusagsm@gmail.com>
>> Sent: Wednesday, April 17, 2019 10:00 PM
>> To: Ron Bonica <rbonica@juniper.net>
>> Cc: Robert Raszuk <robert@raszuk.net>; Tom Herbert <tom@herbertland.com>; SPRING WG <spring@ietf.org>; ipv6@ietf.org; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
>> Subject: Re: [spring] IPv6-compressed-routing-header-crh
>>
>>
>>
>>
>>
>> I agree to make the SID align on word boundaries but I am thinking the software should have hardware independence if at all possible.
>>
>>
>>
>> I think 32 bit is a reasonable size.
>>
>>
>>
>>
>>
>> Gyan S. Mishra
>>
>> IT Network Engineering & Technology Consultant
>>
>> Routing & Switching / Service Provider MPLS & IPv6 Expert
>>
>> www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT
>>
>> Mobile – 202-734-1000
>>
>>
>>
>> Sent from my iPhone
>>
>>
>> On Apr 14, 2019, at 7:54 PM, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
>>
>> Hi Robert,
>>
>>
>>
>> In order to make the CRH ASIC-friendly, we have the following constraints:
>>
>>
>>
>> Support only a small handful of SID lengths
>> If at all possible, make them align on word boundaries
>>
>>
>>
>> Currently, we support 8, 16 and 32 bytes. Do you see a reason why we should support a length greater than 32? Is there some length less than 32 that would be beneficial?
>>
>>
>>
>>                                                      Ron
>>
>>
>>
>>
>>
>>
>>
>> Juniper Internal
>>
>> From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
>> Sent: Friday, April 12, 2019 6:13 PM
>> To: Tom Herbert <tom@herbertland.com>
>> Cc: SPRING WG <spring@ietf.org>; ipv6@ietf.org; Mark Smith <markzzzsmith@gmail.com>; Dino Farinacci <farinacci@gmail.com>; lisp@ietf.org list <lisp@ietf.org>
>> Subject: Re: [spring] IPv6-compressed-routing-header-crh
>>
>>
>>
>> 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
>> > > > --------------------------------------------------------------------
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------