Re: [spring] Thoughts on optimality

Gyan Mishra <> Sat, 18 September 2021 19:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05ABB3A0B0C for <>; Sat, 18 Sep 2021 12:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 PuhFb_V_W455 for <>; Sat, 18 Sep 2021 12:15:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D3453A0B8B for <>; Sat, 18 Sep 2021 12:15:28 -0700 (PDT)
Received: by with SMTP id s11so13129646pgr.11 for <>; Sat, 18 Sep 2021 12:15:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8FWKfJOo+7HDKw2TmoBsWQUN2MtHIO/CKsDJVBnYfGY=; b=JgI5TabbaEhQ56AQTFu34cjmvsd7rf68Ea+w58tmSOHqy8cmKjo4yhgXc6goK2lPyS yZPrjfIbec74N4HK7cEBI54BYcr/uwQ0zxspS8NMUhxhFh0rcrhGRHWHy4SZ/75UQs9a kxotu504S7kmTk85qG++3mNJUGIqiFqlq4xRh+SJnWCOGmLhph+y+GUArHR+7ffa9Ag8 cS8XE3EkdnkdZyKe0+yKjhetEEbO1LV7AbHFiEwpQOAodR6wfmzL6yeaeKwOWVsFVLQo e+QVwgSrNWlRmppupXGSslquA0JzTt2OoJu7fjkX1r5EiZSZGCpUG7JbRU1XBpt+EtTc 0N9g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8FWKfJOo+7HDKw2TmoBsWQUN2MtHIO/CKsDJVBnYfGY=; b=EQ/eEjOFJf6PoZGWQYo8udX6dhQknTEnOUMsjkvrAJZbBHJxLmN213dO4GQ4cqW5Hs wMWpItP4eKuASjgUa17aMzPkbFAueRWQlI9QsXPF4+PlB5ID/SO4q4ZZtsaIC4K7HonL QMDEGX2HQf/qfY+iOzUqrbazZOfQsoymKc/k785Tj11OCPhIM5mxkPln3gE76SD1cieY jTmWlbb8UsC4ifi2W99ytj/Ownvh7g7s5Wy1jDY+iNbbOYp48NOJu3kNi0UMSNVv8Mun Iw/gHiaNVcvOYSJlomPvKCJu3i269xYpEr/7q2e9iGkggTi5pRWkeLNuef7et+PVJXvT qDcg==
X-Gm-Message-State: AOAM531G7m3miEpx7bZ1CG+55AqPGC2N49NCG/YH4aCBuG0lKJdOzG+1 E/+5p0O3Hx2oQ7SxMcotcy7jpKkPh5BNRcpYuJuYp46q
X-Google-Smtp-Source: ABdhPJzxr+Bbh/bKUmFei6YQztL7YdgsIy6U2nI5jsNUqZ6N02+rVVSm9uYfHJBnqDRWkXpRFwuh2EgUhcCn+GzpoH8=
X-Received: by 2002:a63:3c4d:: with SMTP id i13mr16137930pgn.54.1631992526854; Sat, 18 Sep 2021 12:15:26 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Sat, 18 Sep 2021 15:15:16 -0400
Message-ID: <>
To: Bob Hinden <>
Cc: Tony Li <>, spring <>
Content-Type: multipart/alternative; boundary="000000000000d6ddda05cc49def6"
Archived-At: <>
Subject: Re: [spring] Thoughts on optimality
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: Sat, 18 Sep 2021 19:15:35 -0000


Agreed.  As the the goal of the SRv6 compression work is a solution for
encapsulation header size MSD issue for long strict paths, the focus on SRH
header compression of the SRv6 128 bit SID.

>From the analysis draft is stated that each compression solution has
marginal differences and all meet the compression primary objective listed
first in section 6.

As all the proposals are even as far as encapsulation header size, the
compression analysis  results end up boiling down to other factors shown

6 <>.

   Encapsulation Header Size

   o  All proposals meet the requirement to reduce the size of the SRv6
      encapsulation header.  Variances between proposals are negligible.

   Forwarding Efficiency

   o  Overall, the CSID parses the fewest headers.  When per packet
      state is processed per segment, CSID, VSID and UIDSR proposals may
      include it in the routing header, CRH may include it in a
      destination option preceding the CRH.

   o  CSID, VSID, and UIDSR require a single lookup to process an
      adjacency or VPN segment.  CRH always requires 2 lookups for VPN
      segments, and 2 and sometimes 3 lookups for adjacency segments.
      All proposals require two lookups to process a prefix segment and
      the next segment.

   State Efficiency

   o  CSID, VSID and UIDSR minimize forwarding state stored at a node.
      CRH moves per segment state from the packet to the FIB.

   SRv6 Based

   o  CSID is SRv6 based, requiring no updates to existing SRv6
      standards, VSID and UIDSR require updates.  CRH is not strictly
      based on SRv6 but is able to provide equivalent functionality.

   SRv6 Functionality

   o  CSID supports SRv6 functionality.  CRH VSID and UID support SRv6
      functionality or equivalent with some new specifications.

   Heterogeneous SID lists

   o  All proposals support heterogeneous SID lists.  CSID and UIDSR
      support heterogeneous SID lists in the SRH, while CRH and VSID
      require installation of binding SIDs at midpoint nodes.

   SID List Length

   o  All proposals support segment lists of at least 16 segments.

   SID Summarization

   o  VSID, CSID and UIDSR support segment summarization, CRH does not.



On Sat, Sep 18, 2021 at 12:29 PM Bob Hinden <> wrote:

> Hi,
> I think Tony makes an excellent point.   The main purpose of this work is
> to compress the SRv6 header.  I agree with Tony that the w.g. should focus
> on the solution that provides the best header compression.
> Bob
> > On Sep 16, 2021, at 3:23 PM, Tony Li <> wrote:
> >
> >
> > Hi all,
> >
> > We now seem headed to be adopting both the requirements and analysis
> drafts and thoughts start to turn towards the debate for selection.
> >
> > The requirements draft has done a good job documenting our requirements
> and the analysis draft gives us a perspective on how the various proposals
> fulfill those requirements, but a deeper nuance is needed to guide us to
> making an optimal choice.
> >
> > To that end, it seems to me that three of the requirements are paramount:
> >
> > - Encapsulation Header Size
> > - Forwarding Efficiency
> > - State Efficiency
> >
> > Of these three, Forwarding Efficiency and State Efficiency seem like
> they will be overcome by hardware technology.  Continued growth in
> semiconductors will help us scale here, so the remaing requirement of the
> Encapsulation Header Size would seem to predominate, and we should
> therefore optimize for that.
> >
> > Regards,
> > Tony
> >
> > _______________________________________________
> > spring mailing list
> >
> >
> _______________________________________________
> spring mailing list


*Gyan Mishra*

*Network Solutions A**rchitect *

*Email <>*

*M 301 502-1347*