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

Dino Farinacci <farinacci@gmail.com> Fri, 12 April 2019 03:21 UTC

Return-Path: <farinacci@gmail.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 3DBF812003F; Thu, 11 Apr 2019 20:21:12 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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=gmail.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 wLsLDXEacglM; Thu, 11 Apr 2019 20:21:10 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 1050412000F; Thu, 11 Apr 2019 20:21:10 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id p6so4470542pgh.9; Thu, 11 Apr 2019 20:21:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sbx2F0+va19UWW1Udn3ZsqZB6LXf4tM8iBHSMhfY1a4=; b=odLsiNoZu7BUPuqNflTx7X2kyhCzOpbbKhPRUSIQkiw7vyKftc0nkFHTHisA+8PbZv A93cIl000XL/2ejdvCasdSkSMv4dy+ts/JQQYfWlQncdS5qAWgDq24rTa6SZvDamMbwx XJEvpbGX6z6T+lOfhPmSypVNZ33zKBly9/BTqtgt6dT9JyGobz4ExI7zFPoTyqZhjf3U kmVQd5vFsJhxDWCFtqZ4NgqSO+MRqrL7XmkRpUt8ZLQclULfsQB8qPK4mRK/Begp+0m7 yhrCkQjd9Ld485V9ZVRTX9WvA1DjIjwZedbXrnuWYe/lP/adYpljJBDv4kz4o8Oe5L7y Mopw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=sbx2F0+va19UWW1Udn3ZsqZB6LXf4tM8iBHSMhfY1a4=; b=amdETb5qRgt9H08VOJCpTKRW+GdkMShb2w2cX6SlpfHy7ZcXV+X37sWeTACGSH+f1h bKyjrKeAvEDuPn0S7bGPiXlR2oqm47RlopoDvrRUJCaSuxaWl8zs+dDnKNYma9kia+VU Bcz/KWsHhCJtKp4jq7u14B9awTMd3m9NU4RtQY7JMRKa1eT+hYutheVdlpUQY1axG0s8 Jr2aAvpY6f8dmVYsRVcNlsZW9BEWFMu+R4w12iOqzO31a85O2ZY/tVqkllTCZ4G/Atjx 9gkYdb9Y6puZbodbfGDZa5fVdS9p46PVmWc21/5cMfZHSXgvSBHEHGpNqNxsI8DqomFD 1YPw==
X-Gm-Message-State: APjAAAVHZ4wz3ay3/jsMOxO/dl2AeJM7VhXVITrKHrJYBtJkcoM2IQPS HcHyf6MniyJtXTihNzdCYmaAzb+Z
X-Google-Smtp-Source: APXvYqwBAXBvuRX2hMF3QFD2VJxgi+pQ7TGkAQqJHN0/viveFZtGz+QMWMdt38SVUpSMJP7oLOODag==
X-Received: by 2002:aa7:8c84:: with SMTP id p4mr54610982pfd.164.1555039269195; Thu, 11 Apr 2019 20:21:09 -0700 (PDT)
Received: from ?IPv6:2601:646:9600:e494:d8a:730f:c589:c301? ([2601:646:9600:e494:d8a:730f:c589:c301]) by smtp.gmail.com with ESMTPSA id g4sm10009758pfc.75.2019.04.11.20.21.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Apr 2019 20:21:07 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Dino Farinacci <farinacci@gmail.com>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <CAO42Z2w=RaSECTv=pOw1a2ctf=ibViPr7q-vRPiJNTq4MbBn-w@mail.gmail.com>
Date: Thu, 11 Apr 2019 20:21:06 -0700
Cc: Robert Raszuk <robert@raszuk.net>, Robert Raszuk <rraszuk@gmail.com>, SPRING WG <spring@ietf.org>, "ipv6@ietf.org" <ipv6@ietf.org>, lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <95D431A8-12BF-4025-9A50-5A5580EAD0F7@gmail.com>
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> <CAO42Z2w=RaSECTv=pOw1a2ctf=ibViPr7q-vRPiJNTq4MbBn-w@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/Djse5xQLheMiz89A0w1fCf1AWfE>
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 03:21:12 -0000

So it looks like SR is either turning out to be like LISP or BIER, or both. So where is the unique value?

The next step is you’ll need a control plane (where discussions have begun) where it makes SR even more like LISP and support for multicast (where discussions have begun) where it makes SR even more like BIER. 

Dino

> On Apr 11, 2019, at 7:59 PM, Mark Smith <markzzzsmith@gmail.com> wrote:
> 
> Hi Robert,
> 
> Sorry not to get back to you sooner.
> 
>> On Mon, 1 Apr 2019 at 01:40, Robert Raszuk <robert@raszuk.net> wrote:
>> 
>> Hi Mark,
>> 
> <snip>
>> 
>> 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 ?
>> 
> 
> Well, there seems to be or have been concerns about the overhead of
> using 128 bit SIDs in IPv6. That seemed to be the motivation for EH
> insertion.
> 
> I sympathise with the overhead concern, although I'd be quite happy to
> put up with the overhead and bandwidth costs of full IPv6-in-IPv6
> tunnelling in comparison to non-commodity operations like inserting
> the SRH EH into existing IPv6 packets to avoid that overhead.
> Bandwidth is always getting cheaper.
> 
> I think the value in using IPv6 as the transport for SR is that IPv6
> is becoming and will be the future the commodity layer 3 protocol.
> MPLS may be fairly commodity, however IPv6 will be more so, and I
> think the reason is that it is an end-to-end protocol that hosts use
> (I think this is also why Ethernet has become the dominant link-layer
> protocol, even for WAN links).
> 
> So if SR wants to benefit from and leverage IPv6's commodification,
> then it needs to be limited to commodity IPv6 operations. If it
> deviates, then it isn't commodity IPv6 any more.
> 
> So my motivation for suggesting 32 bit SIDs in IPv6, and I'm guessing
> Ron's too for his smaller variable SIDs proposal including 32 bits, is
> to try to reduce the overhead of SR over IPv6, while also retaining
> commodity IPv6 operation.
> 
> Regards,
> Mark.