IETF Logo Mail Archive

Re: [spring] Approaches to MTU efficiency in SRv6 in todays SPRING session

Mark Smith <markzzzsmith@gmail.com> Thu, 25 July 2019 00:50 UTC

Return-Path: <markzzzsmith@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D081203E9 for <spring@ietfa.amsl.com>; Wed, 24 Jul 2019 17:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.497
X-Spam-Level:
X-Spam-Status: No, score=-0.497 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 Shzpr6va01yU for <spring@ietfa.amsl.com>; Wed, 24 Jul 2019 17:50:02 -0700 (PDT)
Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 18B981205D1 for <spring@ietf.org>; Wed, 24 Jul 2019 17:50:02 -0700 (PDT)
Received: by mail-ot1-x32c.google.com with SMTP id r21so43822413otq.6 for <spring@ietf.org>; Wed, 24 Jul 2019 17:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aaMNVBspsTPvhhP7pVtDH8jbA1hBqmRH/apiZTeRZqs=; b=ZRwRfMsWdXo91An1E5gM2//cwFuu2CJiiMZmhuHqiS1PLIXx+X4YDuLOeVO7D2+QT6 hUdNqswwYzh/eHTBNn7633Jl0d61I1xUnTtq43N8/pAZLd/AbF75MxaJldRJVN+1oPhZ 791LEujao7fF0Twaf82Ow1ZllGBr87k2GudUPtY1kvIJwy95S79P+W+ww0yWSRVLRXfB vELd3FV6fYsa1VwjKgaMT7QAicV1YXPAOURBlDvYxtCNBQY3O/Dwm7vcH2xTcultRLSd ZKmg5bLgAjJVMknBfqaROhPbXZx6snya3Kn9vr7C0vNF4qlyoua0Yd55eEEksePIjDSW 2PHg==
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=aaMNVBspsTPvhhP7pVtDH8jbA1hBqmRH/apiZTeRZqs=; b=j23PMvTbu2lKtnAQBKJOM/ba6RMvJWmgPUTLiubeF+hElZ/K4AtNK2F6q4DBCMFwpA qI8l4YMpQBuByp5+n6nGn1ct0LdGNPCXSNNqcgrX4f5F0zUZyI1C+WwhzHoA+XZak2rR sxVq9hYuNKmh4dJtjJDAzUjD8MtWeZM+bOaohca4HmGPFlSG8uxkRjn84LZfvqmR/uFe XPd+So9sSAb9AIm1UAWVjVKXZG7ARpEJIvnXHFOhW7Y5f8sRgZjwpnbHSrjRosDE5+BT QpFhNebT8QlOWc8BZ85H7ynfujQKpuqnW/irqwfPtpSlquS61TZJKLriDIsdVIfq01Dr QjcA==
X-Gm-Message-State: APjAAAVahamgjuHurhM0GGKK2SKxcxaydQOYnSJfDVFI/+QOYQKjMiRP KESUhv2CSvbff3orT/aykQ8e8NEOxXEDnTI1QVBdZw==
X-Google-Smtp-Source: APXvYqx4w4QqFizFsRW2GLtpTYNmchEEk/UCF0TbZ4DH6lG0ip10SpOMBWY0vRVQBbniMkZC8L0EaA0VsR/xNxcRH7U=
X-Received: by 2002:a9d:66d0:: with SMTP id t16mr67324611otm.153.1564015801403; Wed, 24 Jul 2019 17:50:01 -0700 (PDT)
MIME-Version: 1.0
References: <3DE71250-DC8C-4B3B-A1C9-56475A628043@lapishills.com>
In-Reply-To: <3DE71250-DC8C-4B3B-A1C9-56475A628043@lapishills.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Thu, 25 Jul 2019 10:49:49 +1000
Message-ID: <CAO42Z2wHa2LWeJzdXZDrBVk-p-_nGzVgg3R17_3_rWAUnGGFow@mail.gmail.com>
To: Dirk Steinberg <dirk@lapishills.com>
Cc: SPRING WG <spring@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000440c07058e76ce99"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/HcxF1_NWYhPduVuzPiqXI9USl_8>
Subject: Re: [spring] Approaches to MTU efficiency in SRv6 in todays SPRING session
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 00:50:04 -0000

On Thu., 25 Jul. 2019, 02:20 Dirk Steinberg, <dirk@lapishills.com> wrote:

> Hi All,
>
> in todays SPRING session we have heard concerns about
> MTU efficiency in certain use cases involving SRv6.
>
> It is true that using 128 bit SRv6 SIDs trades scalability
> and flexibility against MTU overhead. There will certainly
> be use cases where the additional overhead may be
> justified.
>

I can understand the convenience of SIDs being the same size as the
underlying layer identifier. However, do they have to be?

128 bit SIDs is literally more SID values than there will ever be IPv6
unicast addresses (multicast has 1/8th the space). It's a larger space than
the number of nodes than can be attached to the entire IPv6 Internet.

What size would SIDs be if they were dimensioned only for the SR functions
they're being and going to be used for, rather than just being sized to the
lower layer identifier value?

If MPLS based SIDs are 20 bits, and they do not have any SR functional
constraints, I think that suggests SIDs can be far smaller than 128 bits,
which then addresses the overhead problem 128 bit SIDs creates.



> For other uses cases where MTU efficiency is a major concern
> the answer within the SRv6 framework is SRv6 uSID.
>
> Another proposal to address the MTU efficiency problem today
> advertised itself as basically using the same semantics as MPLS
> encapsulated in IPv6 and also noted that SRv6 deviates from
> legacy MPLS regarding label semantics.
>
> This is exactly the point.
>
> Not being dependent on the legacy MPLS label binding semantics
> in SRv6 is a big advantage.
>
> And this advantage is carried forward in SRv6 uSID as well.
> SRv6 uSID addresses the problem of MTU efficiency while
> avoiding to fall back to MPLS label binding semantics.
>
> No separate mapping table is required to be able to forward uSID.
>
> It is also not true that uSID inflates the IGP and/or FIB tables
> more than other approaches. A uSID is advertised just like
> other SRv6 SIDs, although the prefix length will typically
> be much shorter. The fact that no extra label mapping
> table is required contributes to improved control and
> data plane efficiency and provides excellent forwarding
> ASIC efficiency, especially for low-FIB and legacy systems.
>
> Cheers
> Dirk
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>

v2.23.0 | Report a Bug | By Email