Re: [spring] [srcomp] compression analysis draft question on proposals analyzed

Gyan Mishra <hayabusagsm@gmail.com> Sun, 03 October 2021 20:01 UTC

Return-Path: <hayabusagsm@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 5957A3A0BC6; Sun, 3 Oct 2021 13:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.987
X-Spam-Level:
X-Spam-Status: No, score=-1.987 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, HTTPS_HTTP_MISMATCH=0.1, 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: 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 OM9cpe5Mx3qj; Sun, 3 Oct 2021 13:01:40 -0700 (PDT)
Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 A03BC3A0BB6; Sun, 3 Oct 2021 13:01:40 -0700 (PDT)
Received: by mail-pj1-x1030.google.com with SMTP id pg10so9613173pjb.5; Sun, 03 Oct 2021 13:01:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kJqDTWQD4F+vuN0oWXIe6529m2udL8vaQF6mfRaisHo=; b=lJSd2g8PKIUMiu1au+9D2/LRtjTaFFLXbNUlahM8X4Wr47LEhta3E26dYJSb5asVu+ 0Fe5Iom7uGTh+rZvpQre4bn0IT1UjxEM2p2o1lPYzKvhzuTf0MoLKNa4KUeDDm1S3CXi 5kHmiDTEXhkKWV3SwmrzHPNVYTr9p1bmB+OTq8QJVShzS98+PifDXPwiBQeb6wtUNqW8 l58dQ9t0e3tEQRKyXHtwFXsrhJpGJPzvFgxZkiYOtURyS/P7Y6MbnTw7PwqttD9Ko/SJ AINEE+HZZELR9PV5POTCggOLKdQZBVnOWG8Chfps2z1XbYZQNEqKmZSet5N7K1gyIbl5 Fn/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kJqDTWQD4F+vuN0oWXIe6529m2udL8vaQF6mfRaisHo=; b=tPVhLlTxWC8FmozFo3gYtbQNQoncbGn0L5AtPUbTrcNoJ82hjVLemTzKK73PcCIUsv Iumf5zNUV0x1vY8Ieh0OvxHu8OjzjppT9U7cKp1eKXZJsDn/GPceSGGEiSWCQuMQNMLQ /MdT1R0uuEVWxLzAmuMcjHo/jRQ7PlG5eWeDSVlJIkiQzP3xByVz86M3lsFqN2NZ8RHH UEZ5907z1hHAQgSLLpc8NIPEtJHUiWCSyULAZh9v6W2r92HIKzp6WD4HczsMvNbewiPq 9/581ETD0Rk8yHH7Q59fh0n8Ykrzvge5P1rwIszABYxBSeSWbfy1Hv4zpQ0Jn+McZ08I eo+Q==
X-Gm-Message-State: AOAM532I7r67f3B3a9kChD6COeb+qtitC4PedxLnKc8EJOqKRqR5IbTp W7aNi+X/R4orfmZVdVfuZl9EUauA8rpOnUWt0jkQb3xY
X-Google-Smtp-Source: ABdhPJwaCbqzVasOOiksEJObnrUAB8SZ9d2W17alpo1ziWNQ1AWqWUoikjaE62BxYElYDYH3ooXAihw+L+8yv6fo1KY=
X-Received: by 2002:a17:90b:1642:: with SMTP id il2mr26236744pjb.167.1633291299848; Sun, 03 Oct 2021 13:01:39 -0700 (PDT)
MIME-Version: 1.0
References: <CABNhwV2vMHDV55gu3racFN92reFsZYbgwQku28vQxvPjXL_phA@mail.gmail.com> <CABNhwV1PDbqi_g41S-TMoOvcg3xwSmWYMX8JaGH8X8VCo3gKdQ@mail.gmail.com> <BL0PR05MB5316D38814A1EA6AF74F513CAEA49@BL0PR05MB5316.namprd05.prod.outlook.com> <BN6PR11MB4081AA99FC88D374E11C3149C8A79@BN6PR11MB4081.namprd11.prod.outlook.com>
In-Reply-To: <BN6PR11MB4081AA99FC88D374E11C3149C8A79@BN6PR11MB4081.namprd11.prod.outlook.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Sun, 03 Oct 2021 16:01:28 -0400
Message-ID: <CABNhwV3mTsTpVhoJfu5DXqE-_8O9rUz1BOXHPyJ50ATwTiUsEw@mail.gmail.com>
To: "Darren Dukes (ddukes)" <ddukes=40cisco.com@dmarc.ietf.org>
Cc: SPRING WG <spring@ietf.org>, "srcomp@ietf.org" <srcomp@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000be043205cd784396"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/i-V_oVSANzaBjn2P5m4nJFf8EIM>
Subject: Re: [spring] [srcomp] compression analysis draft question on proposals analyzed
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: Sun, 03 Oct 2021 20:01:55 -0000

Hi Darren & Authors

In addition to that editorial fix can we take below into account and
addressed in the draft.

The main goal for operators is interoperability.  As interoperability is
the key reason for a single SRv6 compression solution that we have WG
consensus and is highly desired.

Continued details of the interoperability study  should be added to the
draft as the study progresses to section 11.

One key detail that is missing is forwarding efficiency and scalability
using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID.

As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for
ultra scale  SRv6 compression solution is recommended for 16 bit SID and
REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32
bit SID.

Of all the requirements as stated, the encapsulation header size is the
primary objective for operators to eliminate MSD issues, keeping in mind
maximizing header reduction at optimal forwarding at line rate and state
efficiencies.

At this time in order for Next and Replace solutions to be interoperable
keeping in mind requirements for optimal forwarding and state efficiency 32
bit SID would be the lowest common denominator between the two solutions
which should be stated as the baseline result of the analysis draft and
added to interoperability section.

Verbiage should state that with the  CSID overall 2 prong next and replace
SID solution that in reality the 32 bit SID would be the optimal lowest
common denominator recommended SID length for interoperability.

The draft should be updated to make more homogeneous between the two
solutions.

Also if it’s possible that uSID GIB/LIB concept can be applied to G-SID
solution to optimize the hardware forwarding and start efficiency to make
16 bit SID viable and recommended G-SID / Replace SID solution.

As stated the primary goal is optimal header size reduction to tackle MSD
issues with interoperability taken into account as CSID is a 2 solution ->
solution.

Kind Regards

Gyan

On Mon, Sep 27, 2021 at 1:23 PM Darren Dukes (ddukes) <ddukes=
40cisco.com@dmarc.ietf.org> wrote:

> Was: Re: [spring]
> draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1
>
>
>
> I’m sending this note to redirect this question to the srcomp DT for an
> editorial fix, when the team meets next.
>
>
>
> For the DT:
>
> Each proposal, introduced in section 1, discusses how it supports 16-bit
> and 32-bit SIDs. However, Gyan’s question indicates this could be more
> clearly stated in the analysis draft to help readers less familiar with a
> proposal.  As such, section 1 can be improved accordingly.
>
>
>
> Darren
>
>
>
> On 2021-09-24, 1:32 PM, "spring" <spring-bounces@ietf.org> wrote:
>
>
>
> Gyan,
>
>
>
> You raise a very good point. In the analysis document, Tables 1 through 6
> and Tables 12 through 15 each contain only one column for the CSID. They do
> not indicate whether the number in that column were calculated using the
> NEXT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not
> indicate whether they were calculated using uSID, G-SID, or a combination
> of both).
>
>
>
> Each of these tables should be modified, so that the CSID column is
> replaced by three columns (NEXT-C-SID, REPLACE-C-SID, and
> NEXT-AND-REPLACE-C-SID).
>
>
>
> If the numbers in these columns are different from one another, this may
> inform our discussion about whether NEXT-C-SID, REPLACE-C-SID, and
> NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a
> behavior.
>
>
>
>
> Ron
>
>
>
>
>
>
>
> Juniper Business Use Only
>
> *From:* spring <spring-bounces@ietf.org> *On Behalf Of *Gyan Mishra
> *Sent:* Friday, September 24, 2021 9:56 AM
> *To:* SPRING WG <spring@ietf.org>;
> draft-filsfilscheng-spring-srv6-srh-compression@ietf.org;
> spring-chairs@ietf.org
> *Subject:* Re: [spring]
> draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Dear Spring Authors
>
>
>
> Please respond to this question the WG has related to which of the three
> SRv6 forwarding mechanisms called  flavors was inclusive of the compression
> analysis draft.
>
>
>
> The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor
> was part of the analysis.
>
>
>
> This is a critical question that has come up by the WG and Chairs, and
> answering this question will help pave the way to an adoption call for
> C-SID.
>
>
>
> Kind Regards
>
>
>
> Gyan
>
>
>
> On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
> Dear Authors
>
>
>
> After having a few discussions on threads related to the SRv6 compression
> analysis draft results, as well as WG coming to consensus on a single SRv6
> compression solution, a few critical questions have come up related to
> C-SID draft that requires clarification by the authors.
>
>
>
> The C-SID draft has 3 compression solutions below and is a combination of
> the two drafts below which introduces 2 of the 3 compression solutions with
> the  C-SID draft introduction of yet a 3rd compression solution.
>
>
>
> Which of the 3 C-SID draft compression solutions was included as part of
> the DT analysis draft results and conclusion?
>
>
>
> This is a critical question that needs to be answered for clarification on
> the C-SID draft solution.
>
>
>
> As the WG has consensus on a single solution we need to have clarification
> from the authors which of the 3 compression solutions was included in the
> analysis.
>
>
>
> The three solutions are very different and all would yield different
> analysis results.
>
>
>
> I understand the authors have called the each solution a endpoint flavor
> which I see from the IANA codepoint allocations, however each flavor is a
> different solution.
>
>
>
> https://www.iana.org/assignments/segment-routing/segment-routing.xhtml
> <https://urldefense.com/v3/__https:/www.iana.org/assignments/segment-routing/segment-routing.xhtml__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZR-kW_YB$>
>
>
>
> So the WG as stated would like a single solution so now we need feedback
> from the authors which of the three solutions or endpoint flavors was part
> of the DT analysis draft that the authors would like to put forward as the
> single compression solution.
>
>
>
> C-SID is a combination of the two drafts below:
>
>
>
> Combination of the two drafts below:
>
>
>
> G-SID - Generalized SID “REPLACE-C-SID”
>
>
> https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-03
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-cmpr-03__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZXk5kUTn$>
>
>
>
> SRv6 uSID micro-segment “ NEXT-C-SID”
>
>
> https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extension-srv6-usid-10__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZWozRCLY$>
>
>
>
> Kind Regards
>
>
>
>
>
> Gyan
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZVS6oNsY$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!XJMCrXOtpr7xttMYGJp3u6tAqsuXrjU7AVELZIzIUxBfFYjzkcL6axEYZVS6oNsY$>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
> *M 301 502-1347*
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*