Re: [spring] RE： WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[Gyan Mishra <[e-mail]>]

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) <[e-mail]> 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:[e-mail]]
> *发送时间:* 2021年10月11日 4:23
> *收件人:* Chengli (Cheng Li) <[e-mail]>; Francois Clad (fclad) <
> [e-mail]>
> *抄送:* James Guichard <[e-mail]>; SPRING WG <
> [e-mail]>; Yisong Liu <[e-mail]>; spring-chairs <
> [e-mail]>
> *主题:* 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) <[e-mail]>
> 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 <[e-mail]> on behalf of Gyan Mishra <
> [e-mail]>
> *Date: *Sunday, 3 October 2021 at 21:01
> *To: *Yisong Liu <[e-mail]>
> *Cc: *James Guichard <[e-mail]>, SPRING WG <
> [e-mail]>, spring-chairs <[e-mail]>
> *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 <[e-mail]>
> 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 <[e-mail]>
>
> 时间: 2021/10/01(星期五)22:04
>
> 收件人: SPRING WG <[e-mail]>;
>
> 抄送人: spring-chairs <[e-mail]>;
>
> 主题: [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
> --
>
> [image: 图像已被发件人删除。] <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*