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

From: Yisong Liu<[email-masked]>
Date: 02 Oct 2021 12:55:32 +0800

Hi Chairs &amp; 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

时间: 2021/10/01(星期五)22:04

收件人: SPRING WG;

抄送人: spring-chairs;

主题: [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:  

   The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors. The document is a “living” document; it may change as it goes through review and analysis by the SPRING working group. 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. 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 &amp; Joel

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 3 Oct 2021 15:00:37 -0400

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-masked]>
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 <[email-masked]>
> 时间: 2021/10/01(星期五)22:04
> 收件人: SPRING WG <[email-masked]>;
> 抄送人: spring-chairs <[email-masked]>;
> 主题: [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-masked]
> https://www.ietf.org/mailman/listinfo/spring
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Fri, 8 Oct 2021 17:34:48 +0000

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-masked]> on behalf of Gyan Mishra <[email-masked]>
Date: Sunday, 3 October 2021 at 21:01
To: Yisong Liu <[email-masked]>
Cc: James Guichard <[email-masked]>, SPRING WG <[email-masked]>, spring-chairs <[email-masked]>
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:

Bottom of section 11:

      combining, in the same SRH ([RFC8754<https://datatracker.ietf.org/doc/html/rfc8754>]), SRv6 SIDs bound to an

King Regards

Gyan
On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chairs & WG,

Best Regards
Yisong

发件人: James Guichard<mailto:[email-masked]>
时间: 2021/10/01(星期五)22:04
收件人: SPRING WG<mailto:[email-masked]>;
抄送人: spring-chairs<mailto:[email-masked]>;
主题: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Dear WG:

  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.".

Thanks!

Jim, Bruno & Joel

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 10 Oct 2021 16:22:52 -0400

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-masked]>
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.
>
>
>
> 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.
>
>
>
>    - 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.
>
>
>
>    - 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.
>
>
>
> *From: *spring <[email-masked]> on behalf of Gyan Mishra <
> [email-masked]>
> *Date: *Sunday, 3 October 2021 at 21:01
> *To: *Yisong Liu <[email-masked]>
> *Cc: *James Guichard <[email-masked]>, SPRING WG <
> [email-masked]>, spring-chairs <[email-masked]>
> *Subject: *Re: [spring] RE： WG Adoption call for
>       combining, in the same SRH ([RFC8754 <https://datatracker.ietf.org/doc/html/rfc8754>]), SRv6 SIDs bound to an
>
>    - "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.".
>
>
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Wed, 13 Oct 2021 10:53:30 +0000

Hi Gyan,

Thanks for your feedback. The authors will work on some more illustrations to add in the draft.

In my previous email (https://mailarchive.ietf.org/arch/msg/spring/ZfbHtQ1FTqWYqjXqcFuEf22I2L8/), I provided an example of how the Next-C-SID and Replace-C-SID flavors could be used together and with different C-SID lengths. Let me restate that, as shown in this example, there is no least common denominator for C-SID lengths between the flavors.

As a side note, could you please use the terminology defined in this C-SID draft or in RFC 8986/8754? Your emails seem to mix them up and makes it difficult for me to understand your questions.

Thanks,
Francois

From: Gyan Mishra <[email-masked]>
Date: Sunday, 10 October 2021 at 22:23
To: Chengli (Cheng Li) <[email-masked]>, Francois Clad (fclad) <[email-masked]>
Cc: James Guichard <[email-masked]>, SPRING WG <[email-masked]>, Yisong Liu <[email-masked]>, spring-chairs <[email-masked]>
Subject: Re: [spring] RE： WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

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 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

   efficiency.

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-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Thanks,
Francois

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 3 October 2021 at 21:01
To: Yisong Liu <[email-masked]<mailto:[email-masked]>>
Cc: James Guichard <[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>, spring-chairs <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] RE： WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Hi Yisong

CSID draft:

Bottom of section 11:

King Regards

Gyan

Best Regards
Yisong

Thanks!

Jim, Bruno & Joel

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 13 Oct 2021 15:37:58 +0000

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-masked]]
发送时间: 2021年10月11日 4:23
收件人: Chengli (Cheng Li) <[email-masked]>; Francois Clad (fclad) <[email-masked]>
抄送: James Guichard <[email-masked]>; SPRING WG <[email-masked]>; Yisong Liu <[email-masked]>; spring-chairs <[email-masked]>
主题: Re: [spring] RE： WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

   efficiency.

Kind Regards

Gyan
Verizon Inc

Thanks,
Francois

Hi Yisong

CSID draft:

Bottom of section 11:

King Regards

Gyan

Best Regards
Yisong

Thanks!

Jim, Bruno & Joel

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

--

[图像已被发件人删除。]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Oct 2021 18:36:41 -0400

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) <[email-masked]> 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
> Gyan>. Good.  That is a very important point.
>
>  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:[email-masked]]
> *发送时间:* 2021年10月11日 4:23
> *收件人:* Chengli (Cheng Li) <[email-masked]>; Francois Clad (fclad) <
> [email-masked]>
> *抄送:* James Guichard <[email-masked]>; SPRING WG <
> [email-masked]>; Yisong Liu <[email-masked]>; spring-chairs <
> [email-masked]>
> *主题:* Re: [spring] RE： WG Adoption call for
> I am really concerned as to how the next and replace interoperability
> would work for adjacent nodes using SID within same or adjacent container.
>
>
>
> 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*
>
>
>
> *6.2 <https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02#section-6.2>.  Block Length*
>
>
>
> 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.
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Oct 2021 18:42:26 -0400

Hi Francois

Most Welcome!

Responses in-line

Kind Regards

Gyan

> Thanks for your feedback. The authors will work on some more illustrations
 Gyan> Excellent!

In my previous email (
https://mailarchive.ietf.org/arch/msg/spring/ZfbHtQ1FTqWYqjXqcFuEf22I2L8/),
I provided an example of how the Next-C-SID and Replace-C-SID flavors could
be used together and with different C-SID lengths. Let me restate that, as
shown in this example, there is no least common denominator for C-SID
lengths between the flavors.

Gyan>  Yes that was a good illustration of mixed lengths between flavors.
I have some comments and will respond to that post.

As a side note, could you please use the terminology defined in this C-SID
draft or in RFC 8986/8754? Your emails seem to mix them up and makes it
difficult for me to understand your questions.

 Gyan> Will do

> Thanks,
>
> Francois
>
>
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Sunday, 10 October 2021 at 22:23
> *To: *Chengli (Cheng Li) <[email-masked]>, Francois Clad (fclad) <
> [email-masked]>
> [email-masked]>, Yisong Liu <[email-masked]>, spring-chairs <
> [email-masked]>
> 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.
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*