Hi Andrew, Thank you for your feedback and for sharing your concerns.
Let me elaborate on top of what Changwang and others have replied. > If there is an implementation done that supports NEXT-C-SID and NOT REPLACE-C-SID – would it inter-operate with an implementation that supports REPLACE-C-SID and not NEXT-C-SID Yes. SRv6 SIDs are processed only by SR segment endpoint nodes (see Sec. 3.3 of RFC 8754). As a result, an implementation supporting NEXT-C-SID flavor does not know nor care if the following segment is REPLACE-C-SID flavor any more than it knows or cares if the following segment is USP, PSP, USD flavor or if its behavior is End, End.X, End.DT, or anything else. > Let me ask you this – which vendor if vendors only support one of the options – is going to be pushing the sids for the other option? Where is the mixed sid push going to happen if vendors only support one part of it? An SR source node (Sec. 3.1 of RFC 8754) need not support any segment endpoint behavior. They just need to encapsulate a packet given a segment list. In this case, they would implement the compression algorithm described in Sec. 7.2 before programming the encapsulation in forwarding, easily supporting any segment endpoint flavors. Hope this helps. Thanks, Francois On 4 Aug 2023 at 14:21:52, Andrew Alston - IETF <andrew-ietf= 40liquid.t...@dmarc.ietf.org> wrote: > Now, > > > > Let me ask you this – which vendor if vendors only support one of the > options – is going to be pushing the sids for the other option? Where is > the mixed sid push going to happen if vendors only support one part of it? > > > > Andrew > > > > > > > > * Internal All Employees From: *linchangwang <linchangwang.04...@h3c.com> > *Date: *Friday, 4 August 2023 at 08:24 > *To: *Andrew Alston - IETF <andrew-i...@liquid.tech>, Joel Halpern < > j...@joelhalpern.com>, SPRING WG List <spring@ietf.org> > *Subject: *RE: [spring] Issue 1 regarding > draft-ietf-spring-srv6-srh-compression > > Hi Andrew,WG, > > > > > > Let me add my understanding of interoperability. > > > > If all devices support NEXT-C-SID, the encapsulation is as follows: > > SRH [0]: block-1 | next-c-sid-21 | next-c-sid-22 | ….| next-c-sid-2n | > SRH [1]: block-1 | next-c-sid-11 | next-c-sid-12 | ….| next-c-sid-1n | > > > > If all devices support REPLACE-C-SID, the encapsulation is as follows: > > SRH [0]: replace-c-sid-2 | replace-c-sid-3 | ….| normal-c-sid-n | > SRH [1]: block-2 | replace-c-sid-1 | > > > > If some devices support NEXT-C-SID and some support REPLACE-C-SID, the > encapsulation for transitioning from REPLACE-C-SID to NEXT-C-SID is as > follows: > > SRH [0]: block-1 | next-c-sid-21 | next-c-sid-22 | ….| next-c-sid-2n | > SRH [1]: block-1 | next-c-sid-11 | next-c-sid-12 | ….| next-c-sid-1n | > SRH [2]: replace-c-sid-2 | replace-c-sid-3 | ….| normal-c-sid-n | > SRH [3]: block-2| replace-c-sid-1 | > > > > If some devices support REPLACE-C-SID and some support NEXT-C-SID, the > encapsulation for transitioning from NEXT-C-SID to REPLACE-C-SID is as > follows: > > SRH [0]: block-2 | replace-c-sid-2 | replace-c-sid-3 | ….| normal-c-sid-n | > SRH [1]: block-2 | replace-c-sid-1 | > SRH [2]: block-1 | next-c-sid-21 | next-c-sid-22 | ….| next-c-sid-2n | > SRH [3]: block-1 | next-c-sid-11 | next-c-sid-12 | ….| next-c-sid-1n | > > > > Therefore, different SIDs can be arranged and co-exist together in one > SRH. > > Devices may only support one forwarding behavior, but different-flavored > SIDs need to be arranged together at the header end for interoperability to > be achieved. > > > > Thanks, > > Changwang > > > > > > *From:* Andrew Alston - IETF [mailto:andrew-i...@liquid.tech] > *Sent:* Friday, August 04, 2023 10:28 AM > *To:* linchangwang (RD); Joel Halpern; SPRING WG List > *Subject:* Re: [spring] Issue 1 regarding > draft-ietf-spring-srv6-srh-compression > > > > Hi Joel, WG > > > > Speaking strictly as a spring participant and wearing no other hats. > > > > I cannot call this one solution – yes – what Changwang said below is > correct that they can potentially co-exist – however the question of one > solution comes down to this: > > > > If there is an implementation done that supports NEXT-C-SID and NOT > REPLACE-C-SID – would it inter-operate with an implementation that supports > REPLACE-C-SID and not NEXT-C-SID > > > > If the answer is no – and I believe at this point it is no – this is not a > single solution – it is two solutions in a single document. The two do not > interoperate together. To argue otherwise would be to say that because we > can put two different SAFI’s under the AFI in BGP that do entirely > different things, if we put them in the same document they somehow become > one solution, because you can run multiple SAFI’s in a single AFI. This is > simply not accurate. > > > > If the document were to mandate implementations both flavors using > normative language – and we had inter-op reports to show this had been > done, then, maybe we could consider this a single solution. Until then, > while we sit in a state that if two implementations only implement half the > draft each – and they cannot cleanly inter-operate – I cannot call this a > single solution. > > > > I write this pointing out that in the past I advocated in the WG for > multiple solutions to the problem, but the WG as I have also stated in the > past, came to clear declared consensus on a single solution, and I believe > that trying to push these into a single document was an attempt to work > around what was already declared consensus, rather than uphold said > consensus and find a true single solution. > > > > So – unfortunately – I must state that as a working group participant, I > do NOT consider this issue closed – and I really fail to see how these can > be considered one solution. > > > > Andrew > > > > > > > > > > Internal All Employees > > *From: *spring <spring-boun...@ietf.org> on behalf of linchangwang < > linchangwang.04...@h3c.com> > *Date: *Tuesday, 1 August 2023 at 03:46 > *To: *Joel Halpern <j...@joelhalpern.com>, SPRING WG List <spring@ietf.org> > *Subject: *Re: [spring] Issue 1 regarding > draft-ietf-spring-srv6-srh-compression > > Hi Joel, WG, > > > > I agree that the issue has been resolved. > > According to the SRv6 dataplane definition in the document > "draft-ietf-spring-srv6-srh-compression,"all SIDs can co-exist in the same > SRH, including Next-C-SID and Replace-C-SID. > > This allows for SRv6 to be a single and consistent dataplane solution. > > > > > > Thanks, > > Changwang > > > > > > *From:* spring [mailto:spring-boun...@ietf.org] *On Behalf Of *Joel > Halpern > *Sent:* Tuesday, August 01, 2023 5:09 AM > *To:* SPRING WG List > *Subject:* [spring] Issue 1 regarding > draft-ietf-spring-srv6-srh-compression > > > > As per the discussions on list and at IETF 117, the SPRING WG chairs > (myself and Alvaro specifically) are attempting to determine if we can > close the open issues regarding > https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ > The editors have entered proposed resolutions for all open issues. This > email is to determine if the working group considers issue 1 closable. > > Issue 1 reads: > > 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. > > The editors have entered: > > All SIDs of the SRv6 dataplane (defined in this document and in other > documents) can co-exist in the same SRH. This make SRv6 a single, > consistent dataplane solution. > > Please speak up if you agree this resolves this issue, or if you consider > that it does not resolve the issue. Objections (and even support if > practical) should be specific as to the technical grounds for the > statement. Silence will not be considered consent. > > This call will run for 3 weeks to allow time for at least some people's > August vacations and in hopes fo getting a clear reading from the WG. > > Separate calls for other issues will be issued on a schedule that the > chairs have selected to try to balance getting sufficient focus with > getting this done, as it has been a long time. > > Note that if the WG agrees that all issues may be marked as closed, the > chairs anticipate issuing the WG last call shortly after that is > determined. Speaking up early will help us in all dimensions. If we > determine that not all issues can be marked as closed, the chairs will work > with the document editors to determine suitable next steps. > > > Thank you, > > Joel > > > > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > This e-mail and its attachments contain confidential information from New > H3C, which is > intended only for the person or entity whose address is listed above. Any > use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender > by phone or email immediately and delete it! > _______________________________________________ > 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
