Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt

Greg Mirsky <> Fri, 20 November 2020 08:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D2993A1A78; Fri, 20 Nov 2020 00:33:51 -0800 (PST)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 plC3LW2C5bAC; Fri, 20 Nov 2020 00:33:49 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3E7F3A1A70; Fri, 20 Nov 2020 00:33:48 -0800 (PST)
Received: by with SMTP id w142so12274631lff.8; Fri, 20 Nov 2020 00:33:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mjW4YJRobalOSzFTlFHTPh04zLPtTcwJEQfF6kf9VfM=; b=h+kfGQ+Ixy+Atkwf95iByEuaL+N3V2tvgUsmodw+z5zx40mGJQXEQE86yBru4uiF2O /c81nYB5JAEK3w7DyQ6hOEFdz5GQ4/r8QGDdf4WwfmlIDIkoHjZ5H3ITev4YQSCkhWTj o/2bMCJi8Q9xJpm3sAuGrz8w3lm9PVg3i3KGzgGXR21l2t4fGKMwRhpxo3DsgRHgiOZA K68vqzJqHPILYi3LK17d+Lhny8KxMCCf94WPwmBYqUFvwImlq4+g1gilZxDpEEVt0FtD IcqYuQkrQYG0ycCaRE5zmfFQkPIxZXUKJgfKWPrAYREUrML7Nzkrk1Ai6/wYD7U+hmZ4 80Yg==
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=mjW4YJRobalOSzFTlFHTPh04zLPtTcwJEQfF6kf9VfM=; b=OY1lDEoqQAy3s4XUj1U7z5eqCihYPB43diuMf01h46BM3vzra4VG62mUuy8WyP0HUw IOIoowitZJexZY3YbYx33DPIiwehOgSImcjdu8eELmqMJKB56ubWWwvpHLKf5On8p2Uq LaAN+fbsueMYaH74ElmLlHgy5o20xDEewN4e5lJH40c1dfVYuc9QAdHVBu2X6ZQfEhii BjYw9TEJWx0YHcZSjx172ePjw7sag4yO6dLpeIcMWS/b9c3VAkQdR92VcmYrJu34lwbU u8RNHf5/VS188hvLYH4hSYpdYKyTL7NHpk1c7+XPOC1JVBjXu+WJ9mNhCxYuipdnIg07 9+9g==
X-Gm-Message-State: AOAM533b45EP4oCVLrHWC3egAZErQvzxw05uEO6jCzjutTo71885tcBK 2EIdwLY+z4G1zrtousCUmCcrmuWBxK/ukid2p2I=
X-Google-Smtp-Source: ABdhPJyD8tUnPZp8J6KS1+UcppmxtABSC63V+/Ww4hAjvu7/LrCR+lDU8MeF4x7XKA3XmbWr8Q51Yvz82bCCPXwJX7M=
X-Received: by 2002:a19:91:: with SMTP id 139mr7398255lfa.331.1605861226908; Fri, 20 Nov 2020 00:33:46 -0800 (PST)
MIME-Version: 1.0
References: <08c001d6b8d3$010d08d0$03271a70$@com> <>
In-Reply-To: <>
From: Greg Mirsky <>
Date: Fri, 20 Nov 2020 00:33:35 -0800
Message-ID: <>
To: Weiqiang Cheng <>
Cc: spring <>, srcomp <>,
Content-Type: multipart/alternative; boundary="000000000000fd11b805b485b321"
Archived-At: <>
Subject: Re: [spring] FW: New Version Notification for draft-srcompdt-spring-compression-requirement-00.txt
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: Fri, 20 Nov 2020 08:33:52 -0000

Dear All,
I took Joel's suggestion. So, here is what I wanted to note:

   - I'd appreciate Chairs' clarification on what sounded as "if the design
   team decides that the SRv6 compression is only required, then we have to
   accept that". I believe that the document the DT will produce still be
   viewed and processed as an individual draft.
   - an then to members of the DT. I would appreciate listening to the
   comments of those who are outside the DT. Particularly, if
   outsiders express their thoughts, impression that the document is leaning
   towards one scenario and seems to overlook another, do not take a defensive
   position right away, engage in a discussion instead.


On Thu, Nov 19, 2020 at 6:32 PM Greg Mirsky <> wrote:

> Hi Weiqiang, members of the DT,
> thank you for volunteering your time and expertise to this important for
> the further development of the SR project. Please find my notes and
> questions below:
>    - my first question is on the intended scope of the document. As I can
>    understand from the title, abstract, the scope is "the requirements for
>    solutions to compress SRv6 SID lists". When I compare that with what was in
>    the charter of the DT in the announcement by our chairs
>    <>
>    :
>  ... the requirements for solutions to compressing segment routing
> information for use over IPv6.
> Though the difference in texts might seems as small, the scopes they
> identify differ significantly. To me, it seems as the scope of the draft is
> targeted to only one possible solution to provide SR over IPv6
> functionality, the SRH. Does the DT plan to expand the scope of the draft
> to match it to its charter?
>    - It appears that in order to qualify whether a proposed
>    compression method complies with the requirement in 3.1.2 an agreement by
>    the WG on the benchmarking method is required because metrics listed, in my
>    view, are platform-dependent.
>    - Though I can appreciate your consideration and using SHOULD in
>    requirement 3.1.3, I don't find it particularly important to be included in
>    the list. After all, it is a matter of the art of implementation.
>    - I think I cannot agree the SID summarization is the only viable
>    technique for the interdomain SR. Replacing MUST with SHOULD might be
>    reasonable, And preferably adding an informative text to describe
>    alternative methods to support the interdomain SR.
>    - I think I understand the intention of the requirement in Section
>    4.2.1 but I may propose expressing it differently:
> A path traversed using a list of compressed SIDs MUST always be the same
> as the path traversed using the list of uncompressed SIDs if no compression
> was applied.
>    - I think that the use of MUST in requirement 5.1 is too strong.
>    Firstly, such compatibility is not essential in a greenfield scenario.
>    Secondly, the control plane based solution might be envisioned to
>    coordinate the interworking between SR domains using SRv6 and not using the
>    SRv6 technique.
> And in the conclusion, once again, many thanks to all the members of the
> Design Team for the job well done.
> Regards,
> Greg
> On Thu, Nov 12, 2020 at 1:06 AM Weiqiang Cheng <
>> wrote:
>> Hi Group,
>> As you know, the SPRING Working Group set up an SR compression design
>> team prior to IETF108.
>> The design team is to produce (rough) consensus (of the DT) outputs to
>> the WG on two related topics:
>> 1) What are the requirements for solutions to compressing segment routing
>> information for use over IPv6;
>> 2) A comparison of proposed approaches to compressing segment routing
>> information for use over IPv6.
>> With great effort of design team members, DT have finished the version
>> -00 of the requirements document and have submitted it to datatracker.
>> Please review it and let's know your comments.
>> B.R.
>> Weiqiang Cheng
>> -----邮件原件-----
>> 发件人: []
>> 发送时间: 2020年11月2日 16:32
>> 收件人: Sander Steffann; SJM Steffann; Weiqiang Cheng
>> 主题: New Version Notification for
>> draft-srcompdt-spring-compression-requirement-00.txt
>> A new version of I-D, draft-srcompdt-spring-compression-requirement-00.txt
>> has been successfully submitted by Weiqiang Cheng and posted to the
>> IETF repository.
>> Name:           draft-srcompdt-spring-compression-requirement
>> Revision:       00
>> Title:          Compressed SRv6 SID List Requirements
>> Document date:  2020-10-30
>> Group:          Individual Submission
>> Pages:          10
>> URL:
>> Status:
>> Htmlized:
>> Htmlized:
>> Abstract:
>>    This document specifies requirements for solutions to compress SRv6
>>    SID lists.
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat
>> _______________________________________________
>> spring mailing list