Hi Chengli Most welcome!
Overall the main point I would like to make that needs to be addressed more clearly in the draft is the interoperability between NEXT and REPLACE SID and a visual diagram of how that would look for same or different SID lengths. As these interoperability permutations have been discussed on ML at length, I think it’s important to address as part of the two flavor solution adding the following mix flavor scenario’s to the draft. No LIB/GIB 1 - Next and Replace SID using common 16 bit SID within the same container. 2- Next and Replace SID using common 32 bit within the same container. 3 - Next 16 bit SID and Replace 32 bit SID using within the same container. 4- Next 32 bit SID and Replace 16 bit SID using within the same container. Common design with LIB/GIB 1 - Next and Replace SID using common 16 bit SID within the same container. -> This is the most optimal solution for mix flavor deployments 2- Next and Replace SID using common 32 bit within the same container. 3 - Next 16 bit SID and Replace 32 bit SID using within the same container. 4- Next 32 bit SID and Replace 16 bit SID using within the same container. Responses in-line Kind Regards Gyan On Wed, Oct 13, 2021 at 11:38 AM Chengli (Cheng Li) <c...@huawei.com> wrote: > Hi Gyan, > > > > Sorry for the late reply. Thank you for reading the draft so carefully, > really appreciated. > Gyan> Welcome > But I will recommend you to split the comments into small emails so that > we can discuss easily. LOL. > Gyan> Will do > Regarding the illustrations, yes, it can be added later on. And also > Francois provides the example already, please refer to it. > > Gyan> Thank you > > 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. > > Gyan> In section 6 please state more clearly and explicitly to the > reader that a common design using GIB/LIB can yield both flavors using 16 > bit SID meeting optimal compression as well as all other requirements. I > think by clearly stating so will really help the drafts adoption by the WG > as it would help put to bed interoperability issues. Also will help > eliminate other mix SID length use cases. Section 6.1 SID length should > then also be updated to state that compression SID length of 16 with > common LIB/GIB usage by both flavors the recommended SID length can be 16 > bit for both flavors and is the most optimal deployable recommendation for > operators if mix flavor is necessary. Also to that end if 16 bit sid can > be utilized optimally with next and replace sid meeting compression and > all other requirements it does put next and replace sid on the same playing > field as equally good solutions that meet the primary goal of optimal > compression. > >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. > > Gyan>. Good. That is a very important point. > > so we should avoid to mix different length of CSIDs in a single container, > though we can do it. > > Gyan> This important verbiage should be added to the draft. > > I think we should add recommendation to avoid mixed flavors within the same domain. Kind Regards Gyan Thanks, > > Cheng > > > > > > > > > > *发件人:* Gyan Mishra [mailto:hayabusa...@gmail.com] > *发送时间:* 2021年10月11日 4:23 > *收件人:* Chengli (Cheng Li) <c...@huawei.com>; Francois Clad (fclad) < > fc...@cisco.com> > *抄送:* James Guichard <james.n.guich...@futurewei.com>; SPRING WG < > spring@ietf.org>; Yisong Liu <liuyis...@chinamobile.com>; spring-chairs < > spring-cha...@ietf.org> > *主题:* 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) <fc...@cisco.com> > 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 <spring-boun...@ietf.org> on behalf of Gyan Mishra < > hayabusa...@gmail.com> > *Date: *Sunday, 3 October 2021 at 21:01 > *To: *Yisong Liu <liuyis...@chinamobile.com> > *Cc: *James Guichard <james.n.guich...@futurewei.com>, SPRING WG < > spring@ietf.org>, spring-chairs <spring-cha...@ietf.org> > *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 <liuyis...@chinamobile.com> > 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 <james.n.guich...@futurewei.com> > > 时间: 2021/10/01(星期五)22:04 > > 收件人: SPRING WG <spring@ietf.org>; > > 抄送人: spring-chairs <spring-cha...@ietf.org>; > > 主题: [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 > > -- > > [image: 图像已被发件人删除。] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > > -- > > [image: 图像已被发件人删除。] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* *M 301 502-1347*
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
