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

Dirk Steinberg <dirk@lapishills.com> Thu, 25 July 2019 12:32 UTC

Return-Path: <dirk@lapishills.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 08BEF12016A for <spring@ietfa.amsl.com>; Thu, 25 Jul 2019 05:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=lapishills-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 EA57DPsmd3cC for <spring@ietfa.amsl.com>; Thu, 25 Jul 2019 05:32:48 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 CDADA1200FF for <spring@ietf.org>; Thu, 25 Jul 2019 05:32:47 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id p17so50568957wrf.11 for <spring@ietf.org>; Thu, 25 Jul 2019 05:32:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lapishills-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Gf1UKfUfizK2ON1NNKNRWX7qeJWxBvpxMciTkFGD5io=; b=N1KIyFL0YBnNBrK7SxOBQWozgp6w+r3QqoN8qw9M30zgVgCxskOevuf/SXalcagPP5 ipT28TCZi5cAXALsAfakpVp1Pxb1WE5nQlsGQ+GkhmLW17XNPnkyzsvd+HUbv2HKACSe 05UpHX5e/LQHiTdjsTyl10i4SMTiUfgz5YMuq2CRO5fJHWV7re52TzN8BusSbhyAINNw iMF9kP7Tze30CWpYyKpPokEQX21IWHJIoCfJkoHBsHahlv1Dd/DElcB2lamP+3DAxqiQ q1GG+2WcSrIG9mIZkL2XL3wMlbeILXTOGbyar/s9XXCb3q0jIKJVm7KmXh1fs2gvrIwb 5npA==
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 :message-id:references:to; bh=Gf1UKfUfizK2ON1NNKNRWX7qeJWxBvpxMciTkFGD5io=; b=B46DvI0wXzBXs+9OTlJjQlpptkhUxZ43p1NLVBV2VeSyMLeIaSt07azlXFjJl2neJc mzdEB7aceRPdgg+DQV/ffxJIjoPR42kXFtKJuFRZxZGV6WZdUU7Ah05+nz7PUjeoUGLL aNzqM/AxHVFy7URvrxIrOO1Ql49GHXmZLeJS4O16MXBUyOEQneW4viwjliQPjF7SOXIh C8MC93Nd2wiieOkuY/gVXPEtRnLuOIaCKBKce3NNWHEisdAPL1uEA+Uggnr2M9mJbv66 YMcUzohpYRd06RWfjwOPAfOasoiUrGilNkX6ltGbkwyeVnL2GgdmhKHSzvwBnPIndjf5 oTag==
X-Gm-Message-State: APjAAAWzb082LJwfH+rpQS/MXrJT21wq3uZq8AB5a2sauCUU/KvbPVgy Eva3VmvKKfFt0ksYy6G0bWqj5Q==
X-Google-Smtp-Source: APXvYqxlkSjZJ4ufrxEHHafeS4hHpZl1h1WJcZHDgNUK77t0qpT9dnFAbDeWRhflJR0SLDOv/k2zXw==
X-Received: by 2002:a5d:48cf:: with SMTP id p15mr45101603wrs.151.1564057965698; Thu, 25 Jul 2019 05:32:45 -0700 (PDT)
Received: from macpro.fritz.box ([92.118.254.40]) by smtp.gmail.com with ESMTPSA id b8sm63040473wmh.46.2019.07.25.05.32.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 05:32:45 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3306123B-E725-4D6B-8015-179365839ADC"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Dirk Steinberg <dirk@lapishills.com>
In-Reply-To: <CAO42Z2wHa2LWeJzdXZDrBVk-p-_nGzVgg3R17_3_rWAUnGGFow@mail.gmail.com>
Date: Thu, 25 Jul 2019 14:32:44 +0200
Cc: SPRING WG <spring@ietf.org>
Message-Id: <529FC0A3-43D6-4A13-B866-E14477B8F140@lapishills.com>
References: <3DE71250-DC8C-4B3B-A1C9-56475A628043@lapishills.com> <CAO42Z2wHa2LWeJzdXZDrBVk-p-_nGzVgg3R17_3_rWAUnGGFow@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/3aRlqLj3U-YLassu1x7SeoPeaKQ>
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 12:32:50 -0000

> Am 25.07.2019 um 02:49 schrieb Mark Smith <markzzzsmith@gmail.com>:
> 
> On Thu., 25 Jul. 2019, 02:20 Dirk Steinberg, <dirk@lapishills.com <mailto: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.

It is important to understand that 128 bit SIDs in SRv6 
in most cases are semantically equivalent to 2 SIDs in
SR-MPLS. This is because the SID contains both a 
locator and a function part (and optionally also an argument).

For example, assuming a 64:64 bit split in SRv6 the 64 bit locator
identifies the router whereas the 64 bit function part identifies
the function (plus optional arguments) which could be a VPN
or an adjacency.

So one SID in SRv6 is equivalent to one transport label plus
one service label in MPLS. For a typical VPN use case that
would be a 2 label stack consisting of the LDP or SR transport
label leading to the egress PE and the VPN label.
The same use case in SRv6 uses only one single SID.

When doing an apples-to-apples comparison of SID sizes
to MPLS label sizes the proper comparison would be 
64 bit  (for example, could also be longer or shorter) in SRv6
to 20 bit in MPLS.

The 20 bit label size in MPLS is a serious limitation for 
large-scale networks and data centers.

Adding uSID into the picture allows the network architect to make
his own choice regarding the tradeoff between identifier length 
and MTU overhead. He may choose to use 64 bits or he can choose
to use 16 bit SRv6 uSIDs. Note that the 16 bit size for uSID is
only an example and in principle the designer could also choose 
to use a different length for uSID, i.e. 32 bit.

Also note that when using SRv6 uSID the semantics regarding
locator and function are again like in MPLS, meaning that one
uSID does NOT designate both locator and function but only one
of the two. For a VPN use case you would need 2 uSIDs just like
in MPLS.

Assuming the vendor implementation of 32 bit uSID in SRv6 in 
addition to 16 bits uSIDs the network designer would have a full 
choice of identifier length: 16 bit, 32 bit (uSID) and 64 bit 
(full SRv6 SID).

> 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 <mailto:spring@ietf.org>
> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>