Hi Francois, Thanks for your responses. Please see inline..
From: Francois Clad (fclad) <fc...@cisco.com> Date: Friday, October 8, 2021 at 1:14 PM To: Tarek Saad <tsaad....@gmail.com>, James Guichard <james.n.guich...@futurewei.com>, SPRING WG <spring@ietf.org> Cc: spring-cha...@ietf.org <spring-cha...@ietf.org> Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Hi Tarek, I am assuming that the border node is an SR segment endpoint node in your question. [TS]: yes. This node processes the packet according to the behavior bound to the locally instantiated SID that was matched (see Section 4.3 of RFC 8754). There is no interpretation required. [TS]: consider the case that two locally instantiated SIDs (carried in the DA) can match – like SID1 is contained within SID2 (or vice versa). Absence anything present in the encoded SID-sequence, how can this node reliably infer whether it is G-SID sequence or a C-CSID sequence? It is the responsibility of the SR source to make sure that the SIDs in the Segment-List are used appropriately. This applies to all SRv6 SIDs, including those defined in RFC 8986. It is the same as ensuring that there is not an End.DT4 SID in the middle of the Segment-List or that an End.X SID bound to the right interface is used. [TS]: I’m not sure it is solely a SR source responsibility. There is some responsibility that the node allocated the 2 kinds of SIDs that need to ensure no such previous collision can ever occur, no? Regards, Tarek Thanks, Francois From: spring <spring-boun...@ietf.org> on behalf of Tarek Saad <tsaad....@gmail.com> Date: Friday, 8 October 2021 at 06:06 To: James Guichard <james.n.guich...@futurewei.com>, SPRING WG <spring@ietf.org> Cc: spring-cha...@ietf.org <spring-cha...@ietf.org> Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Hi all, I’ve read this draft. It is proposing 2 different encodings schemes for compressed sequence of SRv6 SIDs (and an optional behavior on border nodes).. Although Section 4 makes a claim that different deployments usecase may deem one encoding scheme superior over the other, I could not glean in which cases a scheme would outperform the other and why? Or, why is the WG trying to standardize both the two flavors -- keeping in mind the complex HW procedures evident by the proposed different pseudo codes in the draft. Also, are there concerns of misinterpreting (wrongfully decoding) a GSID sequence for a C-SID-sequence (or vice-versa) for a received packet on border nodes that may support both encoding flavors simultaneously? For these reasons, I think this it is still premature for this draft to be adopted, and I oppose its adoption. Regards, Tarek From: spring <spring-boun...@ietf.org> on behalf of James Guichard <james.n.guich...@futurewei.com> Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG <spring@ietf.org> Cc: spring-cha...@ietf.org <spring-cha...@ietf.org> Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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 spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
