Re: [spring] Progressing Standardizing SR over IPv6 compression

Tony Li <> Wed, 04 August 2021 19:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E35CA3A12D4 for <>; Wed, 4 Aug 2021 12:26:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id stg1Y6URc4kq for <>; Wed, 4 Aug 2021 12:26:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 633CC3A12CF for <>; Wed, 4 Aug 2021 12:26:09 -0700 (PDT)
Received: by with SMTP id mt6so4527341pjb.1 for <>; Wed, 04 Aug 2021 12:26:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bkVLi5+D6hxYy8xTFCGRg7p4qgZ66jdogGXzagedpVM=; b=fqAJ+p5tTmNafdAJ6vnauPkmorVRTHuq4FqxYaINJjEltp7KlaDFd6lT/OeH/yntM3 Q437woMcuCwa0z7nJ+Q+QvK+2T8scjvzhgB9yH35hcjvKWOyH/hSxOrtIM2epnDK4+us myP/9g7/DOIapJEfTV4rg7Gh9ku/7cfgXxCaLibqNGUyt9p8ArGlqTAQDolJe0hhza0W ox7/QcYmYGA5yVTAfCtKQls2yiXa5FFNmcisSwdGR3Ezj/5WOWv3NZiyHy6GLqbUGAbj r8vCsOfWuA4nwHkeBW9v/pn839ZTVjlopR++P0apUNoJ4dtbbsiBDj29LF9i/jvb+2v/ Yj/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=bkVLi5+D6hxYy8xTFCGRg7p4qgZ66jdogGXzagedpVM=; b=PtfyKZ7urjat4EJcLUCH6jmgedqMowW2TEJa2NCJKSNCaccaS7V6UdU+wRc/PLXxcR jAaZpQWBrkkclAghGgLaNOVYvIjhGRG2Di+Gmy5Odm1S7QFjerXfPBiMRUes/N1MMTRU i67f4r5TLbaHcjGy/eelz+us6zovB4AcX8tMyK7OJ2srH2bqF6doKottL1fpdxIXisYb Uq8KOgkvaYSXBbDF7d1/ZWUzqh/99FIaneDRRl0g98ee0xWSF767K6r895JMYyGWjr5Y OHd+lNzwzClChpI62hxgFCmL5mwLWfk9GT0JZpZ/zFzfX+iIhvncU0cXhVug3LuJ7NwD OHUA==
X-Gm-Message-State: AOAM532Vxl3nZA6fEFN1RSNTFKwvQdeLTpyHehAUkBSYyOtzLyQj1Zyv yGTxIa3f7KNScZhXLl7W4tc=
X-Google-Smtp-Source: ABdhPJwVyYDfh5dGQwyy3TvAxF182S54LG4+Hpgg2eTy4yhYJ1InYuFnJCCUce9pUug2SHSGIq7HPw==
X-Received: by 2002:a63:f241:: with SMTP id d1mr669126pgk.424.1628105167890; Wed, 04 Aug 2021 12:26:07 -0700 (PDT)
Received: from ( []) by with ESMTPSA id j2sm2622403pfe.72.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Aug 2021 12:26:07 -0700 (PDT)
Sender: Tony Li <>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
From: Tony Li <>
In-Reply-To: <>
Date: Wed, 4 Aug 2021 12:26:05 -0700
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Joel M. Halpern" <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [spring] Progressing Standardizing SR over IPv6 compression
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: Wed, 04 Aug 2021 19:26:13 -0000

> The question we are asking you to comment on is:
> Should the working group standardize one data plane behavior for compressing SRv6 information?


One. And only one.


Let’s suppose that we choose N (or fail to choose).  Different networks will make different choices. Then vendors will be forced to support all N of them. Chip manufacturers will have to support all N of them. Effectively forever. Sure, some may fail, but by that point it becomes impossible to remove the support without re-verifying the chip. So no one will.

Choosing more than one is hideously inefficient for the entire industry.  Our job, as an SDO, is to make a single standard.

The IETF is neither a coffee klatsch nor a publishing house.  Our duty is to make the tough decisions for the world.