From nobody Fri Oct 15 15:47:36 2021 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 735813A1176; Fri, 15 Oct 2021 15:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPLK9NjIwAZW; Fri, 15 Oct 2021 15:38:00 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C6D63A10F4; Fri, 15 Oct 2021 15:36:54 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id m21so9788739pgu.13; Fri, 15 Oct 2021 15:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HhKy8n9RwvjHZjvCWWfEqY05RenrzsCS9xuR029PYME=; b=TAFzGa9qTrbUBKGclG8WxfYIRrazoEnkigklN5bpMIn2zhevILDqXi7xuI3FZtak2V S9ez0PXpA1J0cuJitrHCiwmAVcrNaZpVKKeKXBtH75RZbtLx+JRbTBdIQCuFD/n3hPNl CcjwrjxT+ayGNiitbVl2MzFAnUSjoCJa8k24WwZNM88dhL6bD3UWOzFAyOF1XsuK/tmV EoftTa3P6D0rifmd1SmCWBigvdeZRQ5fSJR3chY56h7/R5DlhCOtJaL+4wUzn9dAwzXS ++/oGR2E5ZpI4oNyuE/XY3RvbsAtHVFedEj/fNVIViL/bLIBYq5vKrP4yGMynnFG1bZX mX4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HhKy8n9RwvjHZjvCWWfEqY05RenrzsCS9xuR029PYME=; b=t+kdAXtMFUvw4DomYZNDJ/KutriJG0d1LpIXB1ZSQSqTpK6CMZYPBCMz8isVj3h3N3 JtX9o7+sShKvfGBzWzEq3kqzYsVVUKb1O0adKydZw2w/9ZXRvrfjjKdwEBVwv+cfhyU9 y+rQRmA/N27oodJhu2k6Kj6pZ4tdddzyrBK+XdLOyE3X6Vl2bRpcgqJi1mmWxxPYgK9N ncliQIhsyIkrxA8olDcw9RZ0WWy8B1OMWuEcKB30ifHS3zJ51sbkItMcg8PPySI+KGmR QZLHMkQg5mgVUpKV28yck+quLimMnlfINCWSvNnYBrKXiOcJ0lh6DizAHYUqMj57Dhi7 Fmnw== X-Gm-Message-State: AOAM5308yQuY8JAfmNOpm6sV9ofvHSwrHyI4ajkcSTZJeFzprj7wp6Ex ol15+7luhymwJrDhAaP28+HN6a+3e8WwRSsIvTY= X-Google-Smtp-Source: ABdhPJwVkWuu38lc8v5yy8phMFIJ6evycJl9SMdGAzqNNcJsWdIUol+NhirIiy7s2Ko8/otvW4vuQTSKVzujYyR5lfE= X-Received: by 2002:a63:b948:: with SMTP id v8mr5229074pgo.243.1634337412898; Fri, 15 Oct 2021 15:36:52 -0700 (PDT) MIME-Version: 1.0 References: <202110021255323466813813@chinamobile.com> <1c919ecf8db842dc8ecda349a74b741c@huawei.com> In-Reply-To: <1c919ecf8db842dc8ecda349a74b741c@huawei.com> From: Gyan Mishra Date: Fri, 15 Oct 2021 18:36:41 -0400 Message-ID: To: "Chengli (Cheng Li)" Cc: "Francois Clad (fclad)" , James Guichard , SPRING WG , Yisong Liu , spring-chairs Content-Type: multipart/related; boundary="000000000000f07b6905ce6bd4c6" Archived-At: Subject: Re: [spring] =?utf-8?q?RE=EF=BC=9A_WG_Adoption_call_for_https=3A//da?= =?utf-8?q?tatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-?= =?utf-8?q?compression/?= X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 22:38:17 -0000 --000000000000f07b6905ce6bd4c6 Content-Type: multipart/alternative; boundary="000000000000f07b6705ce6bd4c5" --000000000000f07b6705ce6bd4c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99s important to address as part of the two flavor solutio= n adding the following mix flavor scenario=E2=80=99s 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) 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 se= e > 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 W= G > 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 fo= r > 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 playi= ng > 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-c= ompression#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 > > > > > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Gyan Mishra [mailto:hayabusagsm@gmail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2021=E5=B9=B410=E6=9C=8811=E6=97= =A5 4:23 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Chengli (Cheng Li) ; Franc= ois Clad (fclad) < > fclad@cisco.com> > *=E6=8A=84=E9=80=81:* James Guichard ; SP= RING WG < > spring@ietf.org>; Yisong Liu ; spring-chairs < > spring-chairs@ietf.org> > *=E4=B8=BB=E9=A2=98:* Re: [spring] RE=EF=BC=9A WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > > > 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 =E2=80=9CNF=3DLocato= r/Function > combo=E2=80=9D 128 bit container based solution and the G-SRV6 32 bit G-= SID > =E2=80=9CNF=3DLocator/Function combo=E2=80=9D 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 th= e > 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 t= he > 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 sty= le > using 16 bit SID and G-SID container style using 32 bit SID. > > > > From the requirements draft, interoperability perspective, the primary > objective is =E2=80=9Cencapsulation header compression=E2=80=9D as that i= s 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 ha= ve > 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 nex= t > 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 eve= n > if the authors state that Replace can use 16 bit SID as a possibility, as > the 32 bit =E2=80=9CNF=E2=80=9D G-SID is recommended for hardware forward= ing 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 . 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 s= o > that would be a major addressing inflexibility for interoperability. > > > > *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 detai= l > 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 contain= er. > > > > 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 bi= t > 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 IP= v6 > address, where the Replace flavor G-SRv6 PGM compression solution indexin= g > the 4 G-SIDs within the container does a Replace at the A-Arg bottom high= er > 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) > 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 l= ength. > - 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 =3D > - IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301:0401:0501 > - SRH =3D > > > - SegmentList[0] =3D 2001:db8:0:1100:d123:: > - SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:0001 > - SegmentList[2] =3D 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 choi= ce. > > > > We can update the draft with this type of illustrations. > > > > Thanks, > > Francois > > > > *From: *spring on behalf of Gyan Mishra < > hayabusagsm@gmail.com> > *Date: *Sunday, 3 October 2021 at 21:01 > *To: *Yisong Liu > *Cc: *James Guichard , SPRING WG < > spring@ietf.org>, spring-chairs > *Subject: *Re: [spring] RE=EF=BC=9A WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > 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 solutio= n. > > > > 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 ]), 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 > 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 plan= e > 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 > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: James Guichard > > =E6=97=B6=E9=97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F=E4=BA=94)22:04 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING WG ; > > =E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs ; > > =E4=B8=BB=E9=A2=98: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > 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-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > 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-comp= ression/ > 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 =E2=80=9Cliving=E2=80=9D 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 docume= nted > in the WG document and maintained by the document editor in conjunctio= n > 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 describin= g 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 multi= ple SRv6 > EndPoint behaviors that some WG members have stated are multiple da= ta 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: =E5=9B=BE=E5=83=8F=E5=B7=B2=E8=A2=AB=E5=8F=91=E4=BB=B6=E4=BA=BA= =E5=88=A0=E9=99=A4=E3=80=82] > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > > -- > > [image: =E5=9B=BE=E5=83=8F=E5=B7=B2=E8=A2=AB=E5=8F=91=E4=BB=B6=E4=BA=BA= =E5=88=A0=E9=99=A4=E3=80=82] > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000f07b6705ce6bd4c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Chengli=C2=A0
Most welcome!

=C2=A0Overall the main point I would like to make that need= s 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 =C2=A0SID lengths.=C2=A0

As these interoperability permutations have been discussed on= ML at length, I think it=E2=80=99s important to address as part of the two= flavor solution adding the following mix flavor scenario=E2=80=99s to the = draft.

=C2=A0No LIB/GIB= =C2=A0

1 - Next and = Replace SID using common 16 bit SID within the same container.=C2=A0
<= div dir=3D"auto">
2- Next and Replace SID using = common 32 bit within the same container.

<= div dir=3D"auto">
3 - Next 16 bit SID and Replace 32 bit S= ID using within the same container.=C2=A0

=
4- Next 32 bit SID and Replace 16 bit SID using within th= e same container.


C= ommon design with LIB/GIB=C2=A0

1 - Next and Replace SID using common 16 bit SID within the same container= . -> This is the most optimal solution for mix flavor deployments=C2=A0<= /div>

2- Next and Replace SID using c= ommon 32 bit within the same container.

3 - Next 16 bi= t SID and Replace 32 bit SID using within the same container.=C2=A0

4- Next 32 bit SID and Replace 16 bit = SID using within the same container.

Responses in-line=C2= =A0

Kind Regards=C2=A0

Gyan


On Wed, Oct 13, 2021 at 11:38 AM Chengli (Cheng Li) <= c.l@huawei.com> wrote:

Hi Gyan,

=C2=A0=

Sorry for the = late reply. Thank you for reading the draft so carefully, really appreciate= d.

Gyan> Welcome=C2= =A0

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">

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 alr= eady, please refer to it.

Gyan> Thank you=C2=A0

Like you quote from the dra= ft, REPLACE-CSID and NEXT-CSID can supported both the 16-bit and 32-bit sol= ution, 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 c= ommon design of GIB/LIB, both flavors can support 16-bit solution. =C2=A0

=C2=A0Gyan> =C2=A0In 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.=C2=A0 I think by clearly stating so wil= l really help the drafts adoption by the WG as it would help put to bed int= eroperability issues.=C2=A0 Also will help eliminate other mix SID length u= se cases.=C2=A0 Section 6.1 SID length should then =C2=A0also 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 th= e most optimal deployable recommendation for operators if mix flavor is nec= essary.=C2=A0 Also to that end if 16 bit sid can =C2=A0be utilized optimall= y 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 sect=
ion 4 in the draft https://datatracker.ietf.org/doc/html/d=
raft-filsfilscheng-spring-srv6-srh-compression#section-4, it also state=
s that
=C2=A0
 It is recommended for ease of operation that a single c=
ompressed

=C2=A0=C2=A0 encoding flavor be used in a given SRv6 domain.=C2=A0 Ho= wever, in a multi-

=C2=A0=C2=A0 domain deployment, different flavors can be used in diff= erent

=C2=A0=C2=A0 domains.

Gyan>. Good.=C2=A0 That is a very impo= rtant point. =C2=A0<= /p>

so we should avoid to mix d= ifferent length of CSIDs in a single container, though we can do it.

=C2=A0Gyan> =C2=A0This important verbi= age should be added to the draft.

=C2=A0 I think we should add recommendation to a= void mixed flavors within the same domain.

Kind Regards=C2=A0

Gyan

Thanks,

Cheng<= /span>

=C2=A0=

=C2=A0=

=C2=A0=

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Calibri,sans-seri= f;color:rgb(31,73,125)">=C2= =A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: Gyan Mishra [= mailto:hayabusagsm@gm= ail.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B410=E6=9C=8811=E6=97=A5 4:23
=E6=94=B6=E4=BB=B6=E4=BA=BA: Chengli (Cheng Li) <c.= l@huawei.com>; Francois Clad (fclad) <fclad@cisco.com>
=E6=8A=84=E9=80=81: James = Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>; Yisong Liu <liuyisong@chinamobile.co= m>; spring-chairs <spring-chairs@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [s= pring] RE=EF=BC=9A WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-= spring-srv6-srh-compression/

=C2=A0

= =C2=A0

Hi Franco= is, Chengli & authors=C2=A0

= =C2=A0

Many Than= ks for your feedback to the WG on the critical topic interoperability of th= e uSID micro-sid 16 bit uSID =C2=A0 =E2=80=9CNF=3DLocator/Function combo=E2= =80=9D =C2=A0128 bit=C2=A0container based solution and the G-SRV6 32 bit G-SID =E2=80=9CNF=3DLocator/Function combo=E2=80=9D 4 - 32 bit G-SID in 12= 8 bit container based solution defined as Next and Replace flavors in the d= raft.

= =C2=A0

I am real= ly concerned as to how the next and replace interoperability would work for= adjacent nodes using SID within same or adjacent container.<= /span>

= =C2=A0

Section 6= .1 mentions that =C2=A0Next flavor recommendation is for 16 bit as the uSID= draft & this draft NF as 16 bit is most optimal uSID size within the u= SID container and=C2=A0Replace flavor recommendation is for 16 bit as the G-SRV6 draft & this draft N= F as 32 bit G-SID is most optimal G-SID size within the G-SID container.=C2= =A0=C2=A0

= =C2=A0

Please =C2=A0elaborate on this in more detail= , as with this draft for next and replace interoperability, following the S= Rv6 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. =C2=A0 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 require= ments each one by one and the problems encountered when not using the recom= mended SID length.=

= =C2=A0

Thus for next and replace flavor interoperabi= lity even possible =C2=A0to work would require two different SID sizes with= in 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.

= =C2=A0

From the requirements draft, =C2=A0interopera= bility perspective, the primary objective is =E2=80=9Cencapsulation header = compression=E2=80=9D as that is what we have spent over a year on with DT finding an optimal compression solution.=C2=A0 So here the= lowest common denominator ends up being 32 bit SID and we now have failed = the primary objective of a compression solution. =C2=A0=C2=A0

= =C2=A0

As far as lowest common denominator is it tru= e that in order to meet all the requirements draft list of all SRv6 compres= sion requirements both next and replace have to revert to that lowest common denominator which is 32 bit SID.=C2= =A0 If that is true, unfortunately that makes the draft fail the primary ob= jective of any SRv6 compression solution.

= =C2=A0

To that end as far as interoperability on Nex= t 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 =E2=80=9CNF=E2= =80=9D G-SID is recommended for hardware forwarding efficiency and scalabil= ity that if 16 bit were used G-SID would fail the hardware forwarding effic= iency and scalability requirements as well as possibly other requirements which should also be stated in the draft.

=C2=A0

6.1.=C2=A0 C-SID Length
=C2=A0

=C2=A0=C2=A0 The NEXT-C-SID flavor supports bo=
th 16- and 32-bit C-SID lengths.=C2=A0 A


=C2=A0=C2=A0 C-SID length of 16-bit is recomme=
nded.


=C2=A0

=C2=A0=C2=A0 The REPLACE-C-SID flavor supports=
 both 16- and 32-bit C-SID lengths.

=C2=A0=C2=A0 A C-SID length of 32-bit is recom=
mended.


=C2=A0

The draft should mention the re= commendation for common block length for interoperability.=C2=A0 The only b= lock size possible is 48 bit so block size so that would be a major address= ing inflexibility for interoperability.

=C2=A0

6.2.=C2=A0 Block Length
=C2=A0

=C2=A0=C2=A0 The recommended SRv6 SID block si=
zes for the NEXT-C-SID flavor are

=C2=A0=C2=A0 16, 32 or 48 bits.=C2=A0 The smal=
ler the block, the higher the compression


=C2=A0=C2=A0 efficiency.


=C2=A0

=C2=A0=C2=A0 The recommended SRv6 SID block si=
ze for the REPLACE-C-SID flavor can

=C2=A0=C2=A0 be 48, 56, 64, 72 or 80 bits, dep=
ending on the needs of the operator.<=
/pre>

=C2=A0

=C2=A0

Taking this further another ste= p as this draft needs to describe in detail with examples of the feasibilit= y of how two adjacent nodes one using next 16 bit SID and other using repla= ce 32 bit SID as recommended where the 16 bit uSID next flavor and 32 bit G-SID are in the same SRH 128 bit conta= iner.

=C2=A0

As the uSID Next flavor draft p= erforms a shift towards B towards nibble A, B nibbles, and Replace does a r= eplace of the A-Arg portion =C2=A0of the 128 bit IPv6 address, how would th= at work with adjacent nodes using different SID flavors of different SID lengths. =C2=A0

=C2=A0

=C2=A0

The Next flavor uSID SRv6 PGM = =C2=A0compression solution process is very different where when indexing th= e micro sid nibbles within the 128 bit container, it performs a shift towar= ds 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 b= its. =C2=A0

=C2=A0

The referencing of the 16 uSID = or 32 =C2=A0bit G-SID =C2=A0nibbles, indexing and reference of which nibble= to referenced for next and replace for directly adjacent nodes with nibble= s within the same 128 bit container or adjacent containers is the interoperability issue that seems to exist. =C2=A0

=C2=A0

This needs to be clarified on t= he next snd replace interoperability operation in detail.

=C2=A0

Also Replace flavor uses COC de= limiter for signaling compression function is active where Next does not ha= ve any signaling of compression being active or not or may have a different= way of signaling that upcoming node does not support compression.=C2=A0=C2=A0

=C2=A0

How does the compression signal= ing interoperability work between Next and Replace flavors.=C2=A0 That shou= ld be addressed as well in the draft.

=C2=A0

Kind Regards

=C2=A0

Gyan

Verizon Inc=C2=A0=

=C2=A0

On Fri, Oct 8, 2021 at 1:34 PM = Francois Clad (fclad) <fclad@cisco.com> wrote:

Hi Gyan,

=C2=A0

It is possible to combine SIDs = of different C-SID flavors and C-SID lengths in the same SRH, along with th= ose defined in RFC 8986 After all, they leverage the same SRv6 data plane.

=C2=A0

Let me give you an example.<= /u>

=C2=A0

Assume that an SR source node w= ants 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.

=C2=A0

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 l= ength.
  • 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 En= d (RFC 8986).
  • On node 11, a SID 2001:db8:0:1100:d123:: bound to End.= DT4 (RFC 8986) for VRF 123.

=C2=A0

The SR source node then sends t= he packet onto the SR path by performing the H.Encaps.Red behavior with:=

  • IPv6 Source Address =3D <an address of the SR sourc= e node>
  • IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301= :0401:0501
  • SRH =3D
    • SegmentList[0] =3D 2001:db8:0:1100:d123::
    • SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:= 0001
    • SegmentList[2] =3D 2001:db8:0:0600:0001::

=C2=A0

Therefore, there is no notion o= f lowest common denominator for C-SID length. Based on the deployment requi= rements, an operator has the flexibility to select the SRv6 SID flavor and C-SID lengths of their choice.

=C2=A0

We can update the draft with th= is type of illustrations.

=C2=A0

Thanks,

Francois

=C2=A0

From: spring <spring-bounces@ietf.org<= /a>> on behalf of Gyan Mishra <hayabusagsm@gmail.com>
Date: Sunday, 3 October 2021 at 21:01
To: Yisong Liu <liuyisong@chinamobile.com>
Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG &l= t;spring@ietf.org&= gt;, spring-chairs <spring-chairs@ietf.org>
Subject: Re: [spring] RE=EF=BC=9A WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

=C2=A0

Hi=C2=A0Yisong

=C2=A0

The main goal for operators is = interoperability.=C2=A0 As interoperability is the key reason for a single = SRv6 compression solution that we have WG consensus and is desired. =C2=A0

=C2=A0

Continued details of the intero= perability study =C2=A0should be added to the draft as the study progresses= .

=C2=A0

One key detail that is missing = is forwarding efficiency and scalability using NEXT-C-SID and REPLACE-C-SID= interoperability using 16 bit SID. =C2=A0

=C2=A0

As NEXT-CSID uSID Container Mic= ro Segment shift flavor using GIB/LIB for ultra scale =C2=A0SRv6 compressio= n solution is recommended for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit SID.=

=C2=A0

Of all the requirements as stat= ed, the encapsulation header size is the primary objective for operators to= eliminate MSD issues with optimal forwarding and state efficiencies.=C2=A0

=C2=A0

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 re= sult of the analysis draft on CSID overall 2 prong solution.<= /span>

=C2=A0

CSID draft:

Bottom of section 11:=

=C2=A0

=C2=A0

=C2=A0 =C2=A0The interoperability was validated for the foll= owing scenario:

=C2=A0=

=C2=A0=C2=A0 o=C2=A0 Packet for=
warding through a traffic engineering segment list
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
combining, in the same SRH ([RFC8754]), SR=
v6 SIDs bound to an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
to an endpoint behavior with the REPLACE-C-SID flavor.
=C2=A0
=C2=A0=C2=A0 Further interopera=
bility testing is ongoing and will be reported in=

=C2=A0=C2=A0 this document as t=
he work progresses.

=C2=A0

King Regards=C2=A0

=C2=A0

Gyan

On Sat, Oct 2, 2021 at 12:56 AM= Yisong Liu <liuyisong@chinamobile.com> wrote:

Hi Chairs & WG,

=C2=A0

I strongly support the = adoption call. Regarding chair's note in the email, I would like to poi= nt 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.

=C2=A0

CSID's next and rep= lace behaviors have been verified by=C2=A0interopera= bility test=C2=A0in China mobile laboratory and there is no proble= m with the interworking of the two behaviors on the CSID dataplane.<= /span>

=C2=A0

Best Regards

Yisong

=C2=A0

=E5=8F=91=E4=BB=B6=E4=BA=BA: James Guic= hard

=E6=97=B6=E9=97=B4: 2021/10/01(=E6= =98=9F=E6=9C=9F=E4=BA=94)22:04=

=E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING WG;

=E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs;

Dear WG:

=C2=A0

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a solution for SRv6 compression.

=C2=A0

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

=C2=A0

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-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

=C2=A0

  1. The SPRING working group is adopting a document that h= as multiple SRv6 Endpoint behaviors.
  2. The document is a =E2=80=9Cliving=E2=80=9D document; i= t may change as it goes through review and analysis by the SPRING working g= roup.
  3. All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the work= ing group to publication. A list of these discussion points will be documen= ted 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 describ= ing an open issue be added to the document in the above-described open issu= es section:
    • "Given that the working group has said that it wa= nts to standardize one data plane solution, and given that the document con= tains 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 pl= ane solution objective.".

=C2=A0

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress 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.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel=

=C2=A0

=C2=A0

_______________________________= ________________
spring mailing list
spring@ietf.org = https://www.ietf.org/mailman/listinfo/spring

--

3D"=E5=9B=BE=E5=83=8F=E5=B7=B2=E8=A2=AB==

Gyan Mishra

Network Solutions Architect=C2=A0<= /i>

Email gyan.s.mishra@verizon.com

M 301 502-1347=

=C2=A0

--

3D"=E5=9B=BE=E5=83=8F=E5=B7=B2=E8=A2=AB=

Gyan Mishra

Network Solutions Architect=C2=A0<= /i>=

Email gyan.s.mishra@verizon.com

M 3= 01 502-1347=

=C2=A0

--
--000000000000f07b6705ce6bd4c5-- --000000000000f07b6905ce6bd4c6 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <17c85fa2c1a4cd34f0f1> X-Attachment-Id: 17c85fa2c1a4cd34f0f1 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAAXAGUBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKK//2Q== --000000000000f07b6905ce6bd4c6--