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 <
[email protected]> 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-compression/
> as the basis for its compression standardization work. That is part of what
> 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-compression/
> 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 “living” 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 documented
> in the WG document and maintained by the document editor in conjunction
> 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 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 that 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.".
>
>
>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/spring
>
_______________________________________________
spring mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/spring
