From nobody Tue Oct 12 21:11:09 2021 Return-Path: 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 DFD283A0BC5; Tue, 12 Oct 2021 21:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: 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: 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 z4jy4EIzYY8S; Tue, 12 Oct 2021 21:11:00 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 93F833A0BCA; Tue, 12 Oct 2021 21:10:57 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id m20so1296650iol.4; Tue, 12 Oct 2021 21:10:57 -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=l7MoSfdDNKI8Bgxop/Ff2LHt8qhPI33fJiOaECdZlxM=; b=R/q14L7U6A4IcY6WWtc1xbHcznxFVecUkq3QEgS2kv0RkGu82H0foCmq+ez3MNqskg i+yfZT0QoAEckDMrRBhKAWcqaWEdI9qE5zIGp2opGIS+Z0hjZCYpU3h64SYHnlsRVtk1 He76FRk4rgduihC2qugm77ChZLeCta6R4k6xivwoTO+Ax0R0f9+likfa1QGO9XI4kM4V YOM23Ijq5fI3XY+ymRcM0IsmBNuShu3WIbcLP/PQ+8PhKQ4+6noMnfxDbwGxNKysYGOn 9nfeZCjTjQFdfCsrnuZAfAPjYfe1UoTkHTrmiWRbLtlAsjPCQn44YQy2CnohmYTBPnlf xtGA== 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=l7MoSfdDNKI8Bgxop/Ff2LHt8qhPI33fJiOaECdZlxM=; b=IZvjyGi2Ck63CIQYx+kGd82f94xbVneUzDLBRGnS3PF9xR6dFrJ3d9B6eusYTT2/XL pRNuDMhkBoaopLhpr8al9iw4/5+3cUbB+HOpCkjyxPYcE8CZczs4oV7Wpg82XxdUwgpc l6p9+iytXms4nmP9Y+JiBakeLuNqvcF8h4vvxI3cnVfYuZue5yIMstfnHklG//4YVvQi NnAEYnZkPd1NCE2e0P1ottfCypZ6yZfG7s32zeIiB0F72huc4sIo3A6VTOFvY/GMokU6 GZev719tyufUSJDFL1l253Zlk4QZ26u4tYoBLYWTisPveADPlva2rnoSQKIKcMkIvye+ QcAQ== X-Gm-Message-State: AOAM532wCW5UJeKOx5BqdiK0LOrQpIv1remD2MqSAxJSuPeukLrCPod8 ZqGSdWa4mVZh6Os7P/QfKmn1nfeBwxRa9PVZd2WGnYBevXc= X-Google-Smtp-Source: ABdhPJxhTDTyXv+W1FknDCCp104LqaeSDuOSDA4tCt9c2d+JCFdtS/qEM+wmoAEju0aD+WCWLou1BSzOFlZNUSEru9k= X-Received: by 2002:a02:c00e:: with SMTP id y14mr16261018jai.68.1634098256604; Tue, 12 Oct 2021 21:10:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Wed, 13 Oct 2021 09:40:19 +0530 Message-ID: To: James Guichard Cc: SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001cf2ad05ce342622" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ X-BeenThere: spring@ietf.org 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, 13 Oct 2021 04:11:05 -0000 --0000000000001cf2ad05ce342622 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chairs, I would not consider new flavors to the existing endpoint behaviors as multiple data planes. At least that's not what I thought of when responding to the earlier poll. Either way, this I-D is a good base for making progress. In fact, making sure that the I-D is in WG control is a much better way to further the discussion. Thus, I support adoption. Thanks to Joel for posting the summary in 6man as well. Some suggestions to authors: - Some sections could use some more explanation and text instead of the reader guessing why. For example section 6.3 - There is a lot of lower case "recommended" in this I-D. Perhaps, some of these might be more suitable as RECOMMENDED. Section 2 o Compressed-SID (C-SID): A C-SID is a short encoding of a SID in SRv6 packet that does not include the SID block bits (locator block). What about the argument? In other places, we say NF is C-SID length (which does not include argument) and thus I am not sure. Section 3 These common bits are named Locator-Block in [RFC8986] I did not find the term "Locator-Block" in RFC 8986. They do use the term SRv6 SID block though. Section 10 Illustrations will be provided in a separate document. An example/illustration is needed to visualize and understand this document. I urge authors to consider adding it as part of this document itself, perhaps as an appendix. Nits - Expand SRv6, SID, PCE on first use. Thanks! Dhruv On Fri, Oct 1, 2021 at 7:35 PM James Guichard < james.n.guichard@futurewei.com> wrote: > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000001cf2ad05ce342622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chairs, <= br>
I would not consider new fla= vors to the existing endpoint behaviors as multiple data planes. At least t= hat's not what I thought of when responding to the earlier poll. Either= way, this I-D is a good base for making progress. In fact, making sure tha= t the I-D is in WG control is a much better way to further the discussion. = Thus, I support adoption. Thanks to Joel for posting the summary in 6man as= well.=C2=A0

Some sug= gestions to authors:

- Some sections could use some more explanation and text instead of the re= ader guessing why. For example section 6.3
- There is a lot of lower case "recommended" in= this I-D. Perhaps, some of these might be more suitable as RECOMMENDED.

Section 2
=C2=A0 =C2=A0o =C2=A0Compressed-SID (C-SID): A C= -SID is a short encoding of a SID in
=C2=A0 =C2=A0 =C2=A0 SRv6 packet th= at does not include the SID block bits (locator
=C2=A0 =C2=A0 =C2=A0 blo= ck).

What about the a= rgument? In other places, we say NF is C-SID length (which does not include= argument) and thus I am not sure.

Section 3

=C2=A0 =C2= =A0These common bits are named Locator-Block in [RFC8986]

I did not find the term "Locator-= Block" in RFC 8986. They do use the term SRv6 SID block though.

Section 10

<= font face=3D"monospace">=C2=A0 =C2=A0Illustrations will be provided in a se= parate document.

An e= xample/illustration is needed to visualize and understand this document. I = urge authors to consider adding it as part of this document itself, perhaps= as an appendix. =C2=A0 =C2=A0

Nits
- Expand S= Rv6, SID, PCE on first use.=C2=A0

Thanks!
Dhr= uv

On Fri, Oct 1, 2021 at 7:35 PM James Guichard <james.n.guichard@futurewei.com<= /a>> wrote:

Dear WG:

=C2=A0

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

=C2=A0

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

=C2=A0

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

=C2=A0

  1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors.
  2. The document is a =E2=80=9Cliving=E2=80=9D docu= ment; it may change as it goes through review and analysis by the SPRING wo= rking group.
  3. All open discussion points raised on our mailin= g list MUST be addressed BEFORE said document is allowed to progress from t= he working group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working grou= p, the chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described open issues section:
    • "Given that the = working group has said that it wants to standardize one data plane solution= , and given that the document contains multiple SRv6 EndPoint behaviors tha= t some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

=C2=A0

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000001cf2ad05ce342622--