Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression

[Cheng Li <[e-mail]>]

Thanks for Changwang¡¯s sharing. Yes, these are some typical examples like said.  As long as it follows the rules of C-SID encoding, a user can encode the C-SIDs in any order he/she likes.
Following your example, another example which can provide better compression is shown below.



SRH [0]: | replace-c-sid-n | ¡­  | replace-c-sid-2 | replace-c-sid-1 |
SRH [1]: | replace-c-sid-n | ¡­  | replace-c-sid-2 | replace-c-sid 1 |
SRH [2]: |  block-1 | next-c-sid-21 | next-c-sid-22 | ¡­.| replace-c-sid-1 |

The last CSID of the first container is a REPLACE-C-SID flavor SID, and it will be shifted to the left when the previous NEXT-C-SID flavor C-SIDs are processed.
In the end, the endpoint node will process this REPLACE-C-SID flavor SID when it is the active C-SID in the container, and then the next REPLACE-C-SID flavor SID from the next container will be updated to the DA.
In this order, the best compression of C-SID sequence can be achieved.  It also proves the resolution provided by the authors.

Respect,
Cheng



From: spring <[e-mail]> On Behalf Of linchangwang
Sent: Friday, August 4, 2023 1:24 PM
To: Andrew Alston - IETF <[e-mail]>; Joel Halpern <[e-mail]>; SPRING WG List <[e-mail]>
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:[e-mail]]
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 ¨C yes ¨C what Changwang said below is correct that they can potentially co-exist ¨C 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 ¨C would it inter-operate with an implementation that supports REPLACE-C-SID and not NEXT-C-SID

If the answer is no ¨C and I believe at this point it is no ¨C this is not a single solution ¨C 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 ¨C 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 ¨C and they cannot cleanly inter-operate ¨C 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 ¨C unfortunately ¨C I must state that as a working group participant, I do NOT consider this issue closed ¨C and I really fail to see how these can be considered one solution.

Andrew





Internal All Employees
From: spring <[e-mail]<mailto:[e-mail]>> on behalf of linchangwang <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 1 August 2023 at 03:46
To: Joel Halpern <[e-mail]<mailto:[e-mail]>>, SPRING WG List <[e-mail]<mailto:[e-mail]>>
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:[e-mail]] 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!