Re: [spring] 答复: SRv6 compression

Robert Raszuk <> Mon, 26 July 2021 20:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 350483A0E1B for <>; Mon, 26 Jul 2021 13:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4kNLvFIbPLi1 for <>; Mon, 26 Jul 2021 13:51:25 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 316C73A0E4C for <>; Mon, 26 Jul 2021 13:51:24 -0700 (PDT)
Received: by with SMTP id f18so17811226lfu.10 for <>; Mon, 26 Jul 2021 13:51:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DlDRTpKNktES+KN52k2mA4F1PTOZ0+nPHB2x5eAKgY0=; b=T38MSY9APqnySk7f5XWKO9gEXo9LSppMKhQyC42lJXbpq+5RMmTwdIZAY/FnoXZYv4 9WJhj4KLv9vG7Cz3zZaGzo/JSevlB5WHoce18v52/ulHmo6kwtbAi7PM+/ep8c34BnUV A2QV7Fjy7owjGLgo7rmOPGmZtwyUoQcUe9VX/ImQUrCZdJWHhzroqMtTtn9w1wjhKvqU hXRuiBEinsJ4WtSr56pnbFFBfJNDZ+OyFbf7Vh4VQ4hMNCeYqrF6dBseHEeHzq/pFF/j PHIL+A7aJIzPpwsssjj0Pe4LQRe2kLW7U12QJWnMgpPbt0qH652+mXpKn3RyCBCxEZ62 wEKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DlDRTpKNktES+KN52k2mA4F1PTOZ0+nPHB2x5eAKgY0=; b=Ys1ZR7wIT+R/H2bDR9yqNHe4rN6gAmtfD1PXB/vIGCshnRt9Zq1SG19lAPz28HJt+F QWG+zh5NSvK6GcoBDMy/Y4M4Aadjah5r2NLRor7PEo9wLw7t2J6OuaYB00V+VNQpIfSf wZnNosh2uIRuTTNO0iPv3K3GLZMdG+jreDO3YUwexchid+T/T7rsROsiY54lLr5R0lut XLdapFC1vapkw3Wl7pu4MPvo8yJcRhFFfE/uPFj0/v6HxfbOwMkczWdT6xcQmbxU+LtN 3h6wUnVHUzM2fOWPnu9SEDkNgwOUKvY+UkJUMtivVFRwa8myPOHIAO+0D7AF24DuJiQ7 Ivtw==
X-Gm-Message-State: AOAM531wJwy2RF9VszC2xYs2OFBP2o8oBzPMhHwzfpOuxqj9sNQ8fdSz ujA8XHKzFBh7gdWbwZQgFSpYBO9NiN3e7JaXRrpIww==
X-Google-Smtp-Source: ABdhPJyR/V3MhZd5Q6oKz9VmiJJ+GeRuFY0r0vsJisrCz9qKOcBosn7NbX7bVybEm1dfuLS/6xqtm5IsX1s3qMvEBdg=
X-Received: by 2002:a05:6512:3dac:: with SMTP id k44mr14824575lfv.541.1627332681037; Mon, 26 Jul 2021 13:51:21 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 26 Jul 2021 22:51:26 +0200
Message-ID: <>
To: "Chengli (Cheng Li)" <>
Cc: Tony Li <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000006290f705c80cea87"
Archived-At: <>
Subject: Re: [spring] =?utf-8?b?562U5aSNOiBTUnY2IGNvbXByZXNzaW9u?=
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Jul 2021 20:51:38 -0000

Hi Cheng,

I think the situation here is as follows. There are few groups of carriers
(SP, ISP, Enterprises):

- group A - cares highly about transport bandwidth efficiency - those will
continue to operate their transport over IPv4 and if needed to steer
packets will use SR-MPLS. For carrying services they can use SR-MPLS or

- group B - does not care about capacity and complexity of the network. If
needed new capacity is added fast. Perhaps their focus is about single
control and data plane and the choice is IPv6. For those IPv6 SIDs with
SRv6 would work just fine and no compression is needed.

- group C - carriers which are coming from group A but willing to play role
in 5G transport or new types of sensor networks. So they are a bit stuck
and seek solutions like header compression of IPv6 as most 5G network
endpoints is using this as a transport. IPv4 there if at all is just an
overlay guest.

Personally I would vote for  variable length SIDs proposal we published
some time back:,
but I guess without solid support from vendors no solution even if sound
matters in IETF nor has any chances to proceed fwd.

Kind regards,

On Mon, Jul 26, 2021 at 10:19 PM Chengli (Cheng Li) <> wrote:

> Hi Tony,
> Thanks you for your comments!
> For sure, our goal is not to deprecate SRv6 but solving the overhead issue
> of SRv6 so that we can use it better.
> That is why we made the effort in the past year and even longer. I believe
> we do not need to state the effort we made in the past many years to finish
> the standard work of SRv6. People know that.
> IMHO, what we(our customers and over 10 vendor partners) need is an
> SRv6-capatible solution that is built based on the existing SRv6 tech with
> minor update.
> Sure, different solution may have their own standard way and I believe
> this can be handled by the WGs. I respect this.
> That is also the point of a standards effort.
> Thanks,
> Cheng
> -----邮件原件-----
> 发件人: spring [] 代表 Tony Li
> 发送时间: 2021年7月27日 3:56
> 收件人:
> 主题: [spring] SRv6 compression
> Hi,
> The chairs ask that we opine on the mailing list, so I’m happy to kick
> things off.
> As I noted within the WG meeting, my preference is that we deprecate SRv6.
> Compressing it then becomes moot and there is no issue.
> Failing that, the WG needs to come to rough consensus on one mechanism.
> That is the point of a standards effort.
> Tony
> _______________________________________________
> spring mailing list
> _______________________________________________
> spring mailing list