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

[linchangwang <[e-mail]>]

Hi Andrew,


Yes, this is a great question.



After implementing compression, networks will have devices with both compression and non-compression capabilities.

Therefore, compression and non-compression SIDs can appear in the same SRH header.

This requires centralized path calculation by the controller and a unified arrangement of SRv6 SIDs after calculating the path.



Next-c-sid and replace-c-sid behave differently and are similar to PSP/USP/USD in that they are essentially a unified SRv6 data plane compression scheme. The choice of which type of compressed SID to use depends on the actual network's SRv6 locator address planning., and

if the common block length is longer, "replace-c-sid" can be used.

If the common block length is shorter, "next-c-sid" is a better option.

Combining these two SID types is ideal for maximum compression efficiency:

SRH [0] | replace c-sid-2 | replace c-sid-3 | ... | replace c-sid-n |
SRH [1] block-1 | next c-sid-1 | next c-sid-2 | ... | replace c-sid-1 |



Therefore, I believe this is a unified compression solution, and vendors should support both options to allow for flexible deployment based on addressing planning in actual networking. In actual deployment, compression and non-compression coexist, and some vendors only support one option. The controller needs to perform mixed SRv6 SID orchestration processing on the head-end device based on the SID flavor type. When the supported options for compressed SIDs are different, similar handling is also required.



The actual deployment may go through the following phases:

1.        non-compressed scenarios

2.        coexistence of compressed and non-compressed

3.        support for both next-c-sid and replace-c-sid based on the characteristics of different networking scenarios.

Thanks,
Changwang

From: Andrew Alston - IETF [mailto:[e-mail]]
Sent: Friday, August 04, 2023 8:22 PM
To: linchangwang (RD); Joel Halpern; SPRING WG List
Subject: Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression

Now,

Let me ask you this ¨C which vendor if vendors only support one of the options ¨C 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 <[e-mail]>
Date: Friday, 4 August 2023 at 08:24
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]> on behalf of linchangwang <[e-mail]>
Date: Tuesday, 1 August 2023 at 03:46
To: Joel Halpern <[e-mail]>, SPRING WG List <[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!