Hi, I support the adoption of both documents.
Thanks for all the effort put in by everyone involved. Few minor comments - *draft-srcompdt-spring-compression-requirement-07* In section 1 It is a goal of the design team to identify solutions to… It is also a goal of the design team to consider proposals… The design team will produce a separate document… Should we still need to mention the design team in the introduction? If some history needs to be maintained, let's put that in the appendix! – In Section 4.2.3 Description: The compression proposal MUST be able to represent SR paths that contain up to 16 segments. Rationale: Strict TE paths require SID list lengths proportional to the diameter of the SR domain. It would be nice to include why the number “16” in the rationale. – We should be explicit that the metric value is “yes” or “no”. This is explicit for some metric (4.1. SRv6 Based) but not for other (4.2.2. Heterogeneous SID lists). – The term “services per node” is not clear to me. Could you add some more text for clarity? – What is the plan for Appendix A? – Nits Expand on first use - SRv6 (currently expanded later) - SID - SPRING - TI-LFA - GUA – In Section 1 The design team will produce a separate document to analyze the proposals. Add reference to draft-srcompdt-spring-compression-analysis – This document is a draft; additional requirements are under review, additional requirements will be added, and current requirements may change. Do we need this? We have the boilerplate for the I-D that highlights it is a “work in progress”! – In Section 3.1.2 D.PRS(segment list): number of headers parsed during processing of the segment list, starting from and including the IPv6 header. “number of extension headers parsed…” and “…including the IPv6 base header” - would be more appropriate phrasing right? – In Section 4.1 Suggest to change U.RFC8402 and U.RFC8754 to U.SR <http://u.sr/> (or U.SRArch) and U.SRH respectively; this would match the descriptive names for other metrics in this section. – In Section 5.1 State that the metric is “yes” when all the conditions are satisfied? – *draft-srcompdt-spring-compression-analysis-02* – Section 3.1 Table 9 mentions updates that need to be made along with Yes. The corresponding requirement does not talk about updates. Should it as you mention it in the conclusion! – Some sections such as 3.4.1, 4.1, 5.1, 5.2, provide no analysis just a conclusion. In some of these, some analysis would be nice or perhaps a clear reference with section number to other documents. – Should section 6 also include the final conclusion after going through each of the requirements? – *Nits* Expand on first use - SRv6 (currently expanded later) - SID - CSID - CRH - TPF - VSID - UIDSR - CFIB - XPS – In Figure 1, you have [M1_0],[C_0], & [M2_0] but the text says 1 is the starting number - o M1_1..M1_i are routers in Metro 1 o C_1..C_j are routers in Core o M2_1..M2_k are routers in Metro 2 – Thanks! Dhruv On Tue, Sep 7, 2021 at 6:43 PM <bruno.decra...@orange.com> wrote: > Dear WG, > > > > > > The Design Team has produced two documents: > > - A requirement document: draft-srcompdt-spring-compression-requirement > > - A solution analysis document: draft-srcompdt-spring-compression-analysis > > > > Both have been presented to the WG and triggered some discussions but are > still individual documents. > > We believe it's now time for the WG to consider taking ownership of those > two documents. > > Note that, especially for those two documents, WG adoption does not > necessarily mean RFC publication in particular if it turns out that the > benefit of long term archive would not justify the WG and IESG effort to > finalize those two documents. > > > > > > This message starts a 2 week WG adoption call, ending September 20th > 2021, for: > > > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement > > > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis > > > > > > After review of the document(s) please indicate support (or not) for WG > adoption of the document(s) to the mailing list. > > Please also provide comments/reasons for your support (or lack thereof) as > this is a stronger way to indicate your (non) support as this is not a vote. > > > > If you are willing to work on the document(s), please state this > explicitly. This gives the chairs an indication of the energy level of > people in the working group willing to work on the document. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
