Hi Gyan, Sorry for the late reply. Thank you for reading the draft so carefully, really appreciated. But I will recommend you to split the comments into small emails so that we can discuss easily. LOL. Regarding the illustrations, yes, it can be added later on. And also Francois provides the example already, please refer to it.
Like you quote from the draft, REPLACE-CSID and NEXT-CSID can supported both the 16-bit and 32-bit solution, but from the considerations of trade-off of better compression and easy operation, NEXT-CSID recommends 16-bit and REPLACE-CSID recommends 32-bit. From the text, you also can see using the common design of GIB/LIB, both flavors can support 16-bit solution. From the section 4 in the draft https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression#section-4, it also states that It is recommended for ease of operation that a single compressed encoding flavor be used in a given SRv6 domain. However, in a multi- domain deployment, different flavors can be used in different domains. so we should avoid to mix different length of CSIDs in a single container, though we can do it. Thanks, Cheng 发件人: Gyan Mishra [mailto:[email protected]] 发送时间: 2021年10月11日 4:23 收件人: Chengli (Cheng Li) <[email protected]>; Francois Clad (fclad) <[email protected]> 抄送: James Guichard <[email protected]>; SPRING WG <[email protected]>; Yisong Liu <[email protected]>; spring-chairs <[email protected]> 主题: Re: [spring] RE： WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Hi Francois, Chengli & authors Many Thanks for your feedback to the WG on the critical topic interoperability of the uSID micro-sid 16 bit uSID “NF=Locator/Function combo” 128 bit container based solution and the G-SRV6 32 bit G-SID “NF=Locator/Function combo” 4 - 32 bit G-SID in 128 bit container based solution defined as Next and Replace flavors in the draft. I am really concerned as to how the next and replace interoperability would work for adjacent nodes using SID within same or adjacent container. Section 6.1 mentions that Next flavor recommendation is for 16 bit as the uSID draft & this draft NF as 16 bit is most optimal uSID size within the uSID container and Replace flavor recommendation is for 16 bit as the G-SRV6 draft & this draft NF as 32 bit G-SID is most optimal G-SID size within the G-SID container. Please elaborate on this in more detail, as with this draft for next and replace interoperability, following the SRv6 compression requirements for optimal hardware forwarding and state efficiency that Next would be recommended to use 16 bit SID and Replace would be recommended 32 bit SID. Please elaborate in detail as to why 16 bit is not recommended for replace flavor and 32 bit is not recommended for next flavor for all of the requirements drafts list of SRv6 compression requirements each one by one and the problems encountered when not using the recommended SID length. Thus for next and replace flavor interoperability even possible to work would require two different SID sizes within the same container interoperability caveats and now you have to deal with uSID container style using 16 bit SID and G-SID container style using 32 bit SID. From the requirements draft, interoperability perspective, the primary objective is “encapsulation header compression” as that is what we have spent over a year on with DT finding an optimal compression solution. So here the lowest common denominator ends up being 32 bit SID and we now have failed the primary objective of a compression solution. As far as lowest common denominator is it true that in order to meet all the requirements draft list of all SRv6 compression requirements both next and replace have to revert to that lowest common denominator which is 32 bit SID. If that is true, unfortunately that makes the draft fail the primary objective of any SRv6 compression solution. To that end as far as interoperability on Next and Replace interoperability being the hinge pin of this drafts adoption, as well even if the authors state that Replace can use 16 bit SID as a possibility, as the 32 bit “NF” G-SID is recommended for hardware forwarding efficiency and scalability that if 16 bit were used G-SID would fail the hardware forwarding efficiency and scalability requirements as well as possibly other requirements which should also be stated in the draft. 6.1<https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-6.1>. C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 32-bit is recommended. The draft should mention the recommendation for common block length for interoperability. The only block size possible is 48 bit so block size so that would be a major addressing inflexibility for interoperability. 6.2<https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-6.2>. Block Length The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are 16, 32 or 48 bits. The smaller the block, the higher the compression efficiency. The recommended SRv6 SID block size for the REPLACE-C-SID flavor can be 48, 56, 64, 72 or 80 bits, depending on the needs of the operator. Taking this further another step as this draft needs to describe in detail with examples of the feasibility of how two adjacent nodes one using next 16 bit SID and other using replace 32 bit SID as recommended where the 16 bit uSID next flavor and 32 bit G-SID are in the same SRH 128 bit container. As the uSID Next flavor draft performs a shift towards B towards nibble A, B nibbles, and Replace does a replace of the A-Arg portion of the 128 bit IPv6 address, how would that work with adjacent nodes using different SID flavors of different SID lengths. The Next flavor uSID SRv6 PGM compression solution process is very different where when indexing the micro sid nibbles within the 128 bit container, it performs a shift towards the top lower order bits of the IPv6 address, where the Replace flavor G-SRv6 PGM compression solution indexing the 4 G-SIDs within the container does a Replace at the A-Arg bottom higher order bits. The referencing of the 16 uSID or 32 bit G-SID nibbles, indexing and reference of which nibble to referenced for next and replace for directly adjacent nodes with nibbles within the same 128 bit container or adjacent containers is the interoperability issue that seems to exist. This needs to be clarified on the next snd replace interoperability operation in detail. Also Replace flavor uses COC delimiter for signaling compression function is active where Next does not have any signaling of compression being active or not or may have a different way of signaling that upcoming node does not support compression. How does the compression signaling interoperability work between Next and Replace flavors. That should be addressed as well in the draft. Kind Regards Gyan Verizon Inc On Fri, Oct 8, 2021 at 1:34 PM Francois Clad (fclad) <[email protected]<mailto:[email protected]>> wrote: Hi Gyan, It is possible to combine SIDs of different C-SID flavors and C-SID lengths in the same SRH, along with those defined in RFC 8986 After all, they leverage the same SRv6 data plane. Let me give you an example. Assume that an SR source node wants to send a packet onto an SR path through 10 SR segment endpoint nodes (nodes 1 through 10), and have a VPN termination for a VRF 123 on a last SR segment endpoint node 11. The SR source node selects the segments as follows: * On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with K being the node ID) bound to End with NEXT-C-SID flavor and 16-bit C-SID length. * On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being the node ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID length. * On node 10, the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986). * On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC 8986) for VRF 123. The SR source node then sends the packet onto the SR path by performing the H.Encaps.Red behavior with: * IPv6 Source Address = <an address of the SR source node> * IPv6 Destination Address = 2001:db8:0:0101:0201:0301:0401:0501 * SRH = * SegmentList[0] = 2001:db8:0:1100:d123:: * SegmentList[1] = 1000:0001:0900:0001:0800:0001:0700:0001 * SegmentList[2] = 2001:db8:0:0600:0001:: Therefore, there is no notion of lowest common denominator for C-SID length. Based on the deployment requirements, an operator has the flexibility to select the SRv6 SID flavor and C-SID lengths of their choice. We can update the draft with this type of illustrations. Thanks, Francois From: spring <[email protected]<mailto:[email protected]>> on behalf of Gyan Mishra <[email protected]<mailto:[email protected]>> Date: Sunday, 3 October 2021 at 21:01 To: Yisong Liu <[email protected]<mailto:[email protected]>> Cc: James Guichard <[email protected]<mailto:[email protected]>>, SPRING WG <[email protected]<mailto:[email protected]>>, spring-chairs <[email protected]<mailto:[email protected]>> Subject: Re: [spring] RE： WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Hi Yisong The main goal for operators is interoperability. As interoperability is the key reason for a single SRv6 compression solution that we have WG consensus and is desired. Continued details of the interoperability study should be added to the draft as the study progresses. One key detail that is missing is forwarding efficiency and scalability using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for ultra scale SRv6 compression solution is recommended for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit SID. Of all the requirements as stated, the encapsulation header size is the primary objective for operators to eliminate MSD issues with optimal forwarding and state efficiencies. At this time in order for Next and Replace solutions to be interoperable keeping in mind requirements for optimal forwarding and state efficiency 32 bit SID would be the lowest common denominator which should be stated as the baseline result of the analysis draft on CSID overall 2 prong solution. CSID draft: https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-11 Bottom of section 11: The interoperability was validated for the following scenario: o Packet forwarding through a traffic engineering segment list combining, in the same SRH ([RFC8754<https://datatracker.ietf.org/doc/html/rfc8754>]), SRv6 SIDs bound to an endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound to an endpoint behavior with the REPLACE-C-SID flavor. Further interoperability testing is ongoing and will be reported in this document as the work progresses. King Regards Gyan On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu <[email protected]<mailto:[email protected]>> wrote: Hi Chairs & WG, I strongly support the adoption call. Regarding chair's note in the email, I would like to point that the network programming model (RFC8996) by nature defines multiple behaviors. CSID has a single SRv6 based data plane that defines the next and replace behaviors consistent with the network programming paradigm. CSID's next and replace behaviors have been verified by interoperability test in China mobile laboratory and there is no problem with the interworking of the two behaviors on the CSID dataplane. Best Regards Yisong 发件人: James Guichard<mailto:[email protected]> 时间: 2021/10/01(星期五)22:04 收件人: SPRING WG<mailto:[email protected]>; 抄送人: spring-chairs<mailto:[email protected]>; 主题: [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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/spring -- [图像已被发件人删除。]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347 -- [图像已被发件人删除。]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email [email protected]<mailto:[email protected]> M 301 502-1347
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
