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

From: James Guichard <[email-masked]>
Date: Fri, 1 Oct 2021 14:04:48 +0000

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

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 1 Oct 2021 14:11:46 +0000

Hi Everyone,

    I support the adoption of this document.

Best Regards,
Huaimo
________________________________
From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Sent: Friday, October 1, 2021 10:04 AM
To: SPRING WG <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C06ea65aba9cd4b33849f08d984e48774%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637686939353945238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ZuL2PerAEvRLWrfqWl9A3ITF4B5Jp7n6zv6JYGEG1qU%3D&reserved=0> 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C06ea65aba9cd4b33849f08d984e48774%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637686939353955195%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=9WTPbXlw1OIZZXdGJ3BWd5WKmZOjWRc9mUxKgT6GZX0%3D&reserved=0> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

  2.  The document is a “living” document; it may change as it goes through review and analysis by the SPRING working group.

Thanks!

Jim, Bruno & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 1 Oct 2021 09:05:05 -0700

Dear WG Chairs,
I have a question about the proposed note to be added if the document is
adopted by the SPRING WG:

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.

It seems that there's some logical contradiction in the note. On one hand,
it acknowledges that the WG unanimously supported adoption of one and only
one data plane solution to compress SRv6 SIDs. Also, the note recognizes
that the draft, as many WG participants stressed in the discussion,
describes at least two different data plane solutions. Given that, I am
puzzled by the phrase "whether this is valid and coherent with its one data
plane solution objective". It seems as contradiction - two solutions are
not coherent with the agreement to standardize a single solution. Perhaps
the note can be more clear about how the WG will achieve "its one data
plane solution objective".

Regards,
Greg

------------------------------
> *From:* spring <[email-masked]> on behalf of James Guichard <
> [email-masked]>
> *Sent:* Friday, October 1, 2021 10:04 AM
> *To:* SPRING WG <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>
> *Subject:* [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/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C06ea65aba9cd4b33849f08d984e48774%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637686939353945238%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ZuL2PerAEvRLWrfqWl9A3ITF4B5Jp7n6zv6JYGEG1qU%3D&reserved=0>
> 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/
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C06ea65aba9cd4b33849f08d984e48774%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637686939353955195%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=9WTPbXlw1OIZZXdGJ3BWd5WKmZOjWRc9mUxKgT6GZX0%3D&reserved=0>
> but with some clear guidelines as follows. By expressing support for
> adoption of this document you are fully aware of and are acknowledging
> that:
>
>
>
>    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
>

---

From: Ron Bonica <[email-masked]>
Date: Fri, 1 Oct 2021 18:07:07 +0000

Chairs,

I strongly object to the adoption of this draft.

I also note that this is a very strange adoption call. The WG has indicated a preference for a single forwarding plane behavior. However, bullets #1 and #4 in the Call for Adoption suggest that the WG has yet to address whether the draft satisfies its single behavior objective.

If the draft does not satisfy the single behavior objective, two of the three behaviors specified in the draft will need to be removed. This is a weak starting point for a standards track RFC.

Furthermore, neither this WG nor 6man has determined whether all three behaviors are compliant with RFC 4291. It seems to me that one is while the other two are not.

Finally, I question the benefit of adopting this draft *before* the above mentioned questions are answered. This is not a rhetorical question. A response from the chairs would be appreciated.

                                                                                                              Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 AM
To: SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

Dear WG:

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!W2v-jx-wb1hsj9oWxKEvtG5Ge9ul-87jmnYS74VaXS02yWsffTe6BMd8sREQndHd$> 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!W2v-jx-wb1hsj9oWxKEvtG5Ge9ul-87jmnYS74VaXS02yWsffTe6BMd8sREQndHd$> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

---

From: Andrew Alston <[email-masked]>
Date: Fri, 1 Oct 2021 20:21:12 +0000

Sorry – but – I’m a little confused here.

Because the way I look at this – the working group clearly stated that they wished for a single behavior – and this – does not deliver that – it is two separate behaviors.  As such – I see this call for adoption – irrespective of the merits or lack thereof of the draft, as a clear defiance of the stated will of the working group.

This is simply does not fit into the definition of bottom up approach in my opinion – and if this is the way that the chairs wish to proceed – then the only way to do that and still fit within the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior approach that the working group agreed to.

As such – I must  strongly and unequivocally object to this call for adoption

Andrew

Date: Friday, 1 October 2021 at 17:05

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<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/<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:

Thanks!

Jim, Bruno & Joel

---

From: Andrew Alston <[email-masked]>
Date: Fri, 1 Oct 2021 20:43:56 +0000

Just to add to this,

I am one of the people who clearly stated that I didn’t think a single solution was the right answer here – and I stated my reasoning clearly on this list.  I still believe that – however – I recognize that the foundation of the IETF is found in the bottom up consensus approach – and when the working group has demonstrated such clear consensus – to defy that – is to defy what makes the IETF the IETF.

So – While I still believe in multiple solutions – irrespective of that – I find this call appalling – because as much as I believe in multiple solutions – the working group consensus should be sacrosanct.

Andrew

From: Andrew Alston <[email-masked]>
Date: Friday, 1 October 2021 at 23:21
To: James Guichard <[email-masked]>, SPRING WG <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Sorry – but – I’m a little confused here.

Andrew

Thanks!

Jim, Bruno & Joel

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 1 Oct 2021 22:54:01 +0200

All,

As agreed by WG and reiterated by chairs during this adoption call WG
agreed for a single data plane solution.

That means that the proposed solution MUST be  fully compliant with the
specifications in [RFC8402], [RFC8754] and [RFC8986].

To me it does not mean that only a single flavor of the encoding within the
above bounds must be allowed.

It would be pretty bad and innovation killing to support one interpretation
of encoded bits and never consider alternative one. Just think that in
modern data plane customer in his domain may download P4 code and setup
forwarding as he seems fit.

Yes on the other hand ASICs may not have that flexibility - well they may
not always be used in programmable networks.

I am under the impression that standardizing RFC8986 which supports many
flavors and behaviours on a single SRv6 data plane with well defined SRH we
agreed that networks can move forward from the current monolith to flexible
forwarding.

The document in question only adds two more flavors. I hope regardless how
it end up with the SPRING gates will not be closed forever for other
proposals with new flavors on how to interpret Locator, Function and
Argument bits in the SRH (yet still bounded by  [RFC8402], [RFC8754] and
[RFC8986]).

For the WG call I support the adoption.

Kind regards,
Robert

On Fri, Oct 1, 2021 at 10:21 PM Andrew Alston <Andrew.Alston=
[email-masked]> wrote:

> Because the way I look at this – the working group clearly stated that
> they wished for a single behavior – and this – does not deliver that – it
> is two separate behaviors.  As such – I see this call for adoption –
> irrespective of the merits or lack thereof of the draft, as a clear
> defiance of the stated will of the working group.
>
>
>
> This is simply does not fit into the definition of bottom up approach in
> my opinion – and if this is the way that the chairs wish to proceed – then
> the only way to do that and still fit within the bottom up approach is to
> first ask this working group for its consensus to deviate from the single
> behacvior approach that the working group agreed to.
>
>
>
> *From: *spring <[email-masked]> on behalf of James Guichard <
> *Date: *Friday, 1 October 2021 at 17:05
> *To: *SPRING WG <[email-masked]>
> *Cc: [email-masked] <[email-masked]>
> *Subject: *[spring] WG Adoption call for

---

From: Tony Li <[email-masked]>
Date: Fri, 1 Oct 2021 13:54:57 -0700

+1

I object to the adoption.

Tony

> On Oct 1, 2021, at 1:43 PM, Andrew Alston <Andrew.Alston=[email-masked]> wrote:
> 
> Just to add to this,
>  
> From: Andrew Alston <[email-masked] <mailto:[email-masked]>>
> To: James Guichard <[email-masked] <mailto:[email-masked]>>, SPRING WG <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ <https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/>
> The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ <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/ <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.".
>

---

From: Gyan Mishra <[email-masked]>
Date: Fri, 1 Oct 2021 19:26:01 -0400

Dear WG chairs,

I agree with Greg Mirsky that the adoption guidelines are confusing and
contradictory.

Bullet  #1 states that by expressing support for adoption the WG member is
agreeing to adoption of a document that has multiple SRv6 compression
solutions.

On the other hand bullet #4 states that if the draft is adopted that the
following text excerpt below should be added to as an open issue 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.".

This sentence is very confusing as the WG chairs agree that the WG has
consensus on a single solution to avoid interoperability, and the WG chairs
acknowledge that some WG members feel that the multiple flavors are
actually multiple solutions, how is it possible that the WG would address
that this is as valid and coherent with one date plane solution as the
objective.  The valid and coherent part of how a multiple data plane
solution or flavor meets the single data plane objective is contradictory.

 I believe what is stated here by the chairs is exactly what should have
been cleared up prior to the adoption call, but now as the adoption call
has started  would be cleared up during the adoption call process.  This is
somewhat of a chess game as to which way to have proceeded, but I think
getting this cleared up prior to the call for adoption would have been
better for the WG.

All WG members that feel strongly that the two endpoint flavors are two
distinctly different solutions will stick to their guns and support not
adopting the document.

All WG members that are Ok with two solutions versus a single SRV6
compression solution will chose to adopt the draft.

The down side of not resolving this issue prior to adoption call  is that
there is a chance the many that felt strongly for a single solution as risk
of interoperability issues as all vendors due to cost may not want to
implement multiple compression solutions and may not all pick the same
compression solution.

So there could be a unanimous vote to not adopt as this goes against the WG
consensus on a single data plane solution.

I agree that is not a major risk going this route as the draft would be
kicked back to the authors to revise and pick one of the flavors to put
forward for adoption.

The flip side is we are back to the drawing board with the DT on WG
consensus on a compression solution to agree to for an adoption call.

Kind Regards

Gyan

On Fri, Oct 1, 2021 at 4:55 PM Tony Li <[email-masked]> wrote:

> On Oct 1, 2021, at 1:43 PM, Andrew Alston <
> Andrew.Alston=[email-masked]> wrote:
>
> Just to add to this,
>
> I am one of the people who clearly stated that I didn’t think a single
> solution was the right answer here – and I stated my reasoning clearly on
> this list.  I still believe that – however – I recognize that the
> foundation of the IETF is found in the bottom up consensus approach – and
> when the working group has demonstrated such clear consensus – to defy that
> – is to defy what makes the IETF the IETF.
>
> So – While I still believe in multiple solutions – irrespective of that –
> I find this call appalling – because as much as I believe in multiple
> solutions – the working group consensus should be sacrosanct.
>
> Andrew
>
>
>
> *From: *Andrew Alston <[email-masked]>
> *Date: *Friday, 1 October 2021 at 23:21
> *To: *James Guichard <[email-masked]>, SPRING WG <
> [email-masked]>
> *Subject: *Re: WG Adoption call for
>  as the basis for its compression standardization work. That is part of
> what this email attempts to confirm.
>
> adoption of this document you are fully aware of and are acknowledging that:
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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

*M 301 502-1347*

---

From: <[email-masked]>
Date: Sun, 3 Oct 2021 09:12:55 +0800 (CST)

Hi Chaires and WG,

I support to adoption this draft. As we known, the draft has been discussed in the DT for more than 2 years. The requirement draft has been accepted and adopted by WG. The solution compatible with the standard SRv6 is preferred for the SRv6 compression, that is the solution provided by this draft. And I think the solution proposed by this draft is just one solution with 2 flavors, which share the same SRv6 processes. The provider/user could use the flavors according to their SID planning, just like using other flavors.

Best regards,

Aihua

原始邮件

发件人：JamesGuichard
收件人：SPRING WG;
抄送人：[email-masked];
日 期 ：2021年10月01日 22:07
主 题 ：[spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

 

 

 

 

Thanks!

Jim, Bruno & Joel

---

From: "Yangfan(Fan,IP Standards)" <[email-masked]>
Date: Sun, 3 Oct 2021 17:19:21 +0000

Hi Spring,

I have read the draft, and I think it is well-written and mature enough to be adopted. CSID can be a good basis for SRv6 compression, let's adopt it and move forward. More issues can be addressed in the standard progress.

Best regards,
Fan

发件人：James Guichard <[email-masked]>
收件人：SPRING WG <[email-masked]>
抄 送：spring-chairs <[email-masked]>
时 间：2021-10-01 22:06:07
主 题：[spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: James Guichard <[email-masked]>
Date: Mon, 4 Oct 2021 15:09:37 +0000

Andrew,

As stated in our email of September 9th, the chairs communicated that the working group reached rough (quite clear) consensus for standardizing one data plane solution to compress segment routing over IPv6. In addition to this there was an inclination toward using the CSID document as the basis for our work in this area. The chairs recognized that there was however disagreement as to whether this document, having multiple SRv6 EndPoint behaviors, could be considered consistent with the working group consensus for a single data plane solution. This issue quite clearly needed to be addressed, and the chairs, recognizing that the working group is keen to make progress in this area, had the option of trying to resolve the issue prior to issuing an adoption call, or give the working group the opportunity to express their opinions as part of a call for adoption.

Those who feel that we need to resolve the consistency issue before adoption, as with those who think this is not a good basis for the WG work, are free and expected to object to the WG adopting the document. That is distinct from objecting to the chairs issuing the adoption call.

In essence, the chairs have combined the question of when to resolve consistency and the question of whether this document is a good basis for the WG into one call.

Yours,

Jim, Bruno & Joel

From: Andrew Alston <[email-masked]>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Sorry - but - I'm a little confused here.

Because the way I look at this - the working group clearly stated that they wished for a single behavior - and this - does not deliver that - it is two separate behaviors.  As such - I see this call for adoption - irrespective of the merits or lack thereof of the draft, as a clear defiance of the stated will of the working group.

This is simply does not fit into the definition of bottom up approach in my opinion - and if this is the way that the chairs wish to proceed - then the only way to do that and still fit within the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior approach that the working group agreed to.

As such - I must  strongly and unequivocally object to this call for adoption

Andrew

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of James Guichard <[email-masked]<mailto:[email-masked]>>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Dear WG:

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C5e0d0fdb84404b53517108d98519075f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687164816496052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BVsL9%2BHgyiQLb7%2FoAY437Vek4bhHWMrl3KdoTPbAnGU%3D&reserved=0> 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C5e0d0fdb84404b53517108d98519075f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687164816506046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=67Ot32mHEqz0JXCc01%2BuI6I1WPOzrwrCTEp3rp9cVE8%3D&reserved=0> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

---

From: James Guichard <[email-masked]>
Date: Mon, 4 Oct 2021 15:13:41 +0000

Hi Gyan,

Please see the chairs response to the email from Andrew Alston.

Yours,

Jim, Bruno & Joel.

From: Gyan Mishra <[email-masked]>
Sent: Friday, October 1, 2021 7:26 PM
To: Tony Li <[email-masked]>
Cc: Andrew Alston <Andrew.Alston=[email-masked]>; James Guichard <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG chairs,

I agree with Greg Mirsky that the adoption guidelines are confusing and contradictory.

Bullet  #1 states that by expressing support for adoption the WG member is agreeing to adoption of a document that has multiple SRv6 compression solutions.

On the other hand bullet #4 states that if the draft is adopted that the following text excerpt below should be added to as an open issue issues section.

This sentence is very confusing as the WG chairs agree that the WG has consensus on a single solution to avoid interoperability, and the WG chairs acknowledge that some WG members feel that the multiple flavors are actually multiple solutions, how is it possible that the WG would address that this is as valid and coherent with one date plane solution as the objective.  The valid and coherent part of how a multiple data plane solution or flavor meets the single data plane objective is contradictory.

 I believe what is stated here by the chairs is exactly what should have been cleared up prior to the adoption call, but now as the adoption call has started  would be cleared up during the adoption call process.  This is somewhat of a chess game as to which way to have proceeded, but I think getting this cleared up prior to the call for adoption would have been better for the WG.

All WG members that feel strongly that the two endpoint flavors are two distinctly different solutions will stick to their guns and support not adopting the document.

All WG members that are Ok with two solutions versus a single SRV6 compression solution will chose to adopt the draft.

The down side of not resolving this issue prior to adoption call  is that there is a chance the many that felt strongly for a single solution as risk of interoperability issues as all vendors due to cost may not want to implement multiple compression solutions and may not all pick the same compression solution.

So there could be a unanimous vote to not adopt as this goes against the WG consensus on a single data plane solution.

I agree that is not a major risk going this route as the draft would be kicked back to the authors to revise and pick one of the flavors to put forward for adoption.

The flip side is we are back to the drawing board with the DT on WG consensus on a compression solution to agree to for an adoption call.

Kind Regards

Gyan

On Fri, Oct 1, 2021 at 4:55 PM Tony Li <[email-masked]<mailto:[email-masked]>> wrote:

+1

Tony

On Oct 1, 2021, at 1:43 PM, Andrew Alston <Andrew.Alston=[email-masked]<mailto:Andrew.Alston=[email-masked]>> wrote:

Just to add to this,

I am one of the people who clearly stated that I didn't think a single solution was the right answer here - and I stated my reasoning clearly on this list.  I still believe that - however - I recognize that the foundation of the IETF is found in the bottom up consensus approach - and when the working group has demonstrated such clear consensus - to defy that - is to defy what makes the IETF the IETF.

So - While I still believe in multiple solutions - irrespective of that - I find this call appalling - because as much as I believe in multiple solutions - the working group consensus should be sacrosanct.

Andrew

From: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Date: Friday, 1 October 2021 at 23:21
To: James Guichard <[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781607659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=raeliPDdAE3XWeVOVAUVQADo0QZnB%2FFbJF53iA5M1BQ%3D&reserved=0>
Sorry - but - I'm a little confused here.

Andrew

Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781617653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xo7OrRUKD4JQtAh2%2BkojPS9ZUuooLvFAZaA6KGE0eKM%3D&reserved=0>
Dear WG:

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781617653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xo7OrRUKD4JQtAh2%2BkojPS9ZUuooLvFAZaA6KGE0eKM%3D&reserved=0> 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781627651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3sWcvuW3MBDx5N82N3fOi43DC2o2fvuIGYFQ%2Be0xpEY%3D&reserved=0> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781627651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3EbeqZCC8Vu%2B8h56CW6N5Z%2BuD00N2sv%2BLzihrH7f6iE%3D&reserved=0>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781637641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k8Xzm3PKEWDd%2FEyOUEoluj3kjmThkLj7eLLlmPJqIZY%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781637641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fflOAQvZXQ1f3%2BCoOicSgdDv%2B7wdKCP4vcZ0hayB1BA%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

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

M 301 502-1347

---

From: Andrew Alston <[email-masked]>
Date: Mon, 4 Oct 2021 15:27:28 +0000

Jim,

Sorry - but - if the working group said one solution - and you acknowledge that there is an issue as to if this represents one or multiple solutions - but proceed to call for adoption anyway - on the basis that this can be resolved post adoption - you create a very problematic solution if it is decided these are two solutions.  Because you will have adopted something if defiance of an already reached consensus at this point.  The issue has to be resolved before hand.

For the record - I will support multiple solutions - as I always have - but - again - if there is disagreement over if this represents one solution or multiple - and the working group has said use ONE - then pure reasoning stands that the issue of if this is one or multiple has to be resolved - and if we decide it is two solutions - then a further working group consensus call needs to be made to determine if we are going to stick with the original decision.

I would also like to hear the thoughts on multiple data plane solutions in this regard from the working group chairs in 6man and the relevant AD's.  I point to the spring charter which explicitly states that work that modifies or extends a data plane has to be done with the agreement of the AD's and working group chairs of the relevant area that holds the data plane (in this case 6man), and so - can we get some feedback there before this is adopted as to - if they view this as a single option - or multiple - and if they support this combination as we are proposing.

Thanks

Andrew

From: James Guichard <[email-masked]>
Sent: Monday, October 4, 2021 6:10 PM
To: Andrew Alston <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Andrew,

Yours,

Jim, Bruno & Joel

From: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression>

Andrew

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

Thanks!

Jim, Bruno & Joel

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 4 Oct 2021 15:29:29 +0000

I support the adoption for the following reasons:

  1.  If you look at the analysis, CSID has the best attributes for the compressed SRv6 solution in IETF.
  2.  Adopting a WG means we put in some guidance on the direction of IETF. Even we still need to discuss more on the different behaviors in CSID; In my view it can happen when we progress the CSID doc in the WG.
  3.   We have spent already substantial amount of time and effort on this and it is time to move forward and have decisions.

Date: Friday, 1 October 2021 at 16:05

Thanks!

Jim, Bruno & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 4 Oct 2021 08:46:34 -0700

Hi Jim,
thank you for the detailed explanation of the considerations the WG Chairs
went through before starting the WG AP. As I understand it, the C-SID
proposal integrates two mechanisms that were presented to the SPRING WG and
thoroughly discussed as separate drafts. These are uSID and GSRv6. Looking
at the list of the requirements and the analysis of CSID, I believe that it
is safe to conclude that, as components of C-SID, uSID and GSRv6 are
conformant to all the requirements. If that is the case, has anyone in the
WG considered that the WG may adopt either uSID or SRv6 document as the
basis of the standard compressing SRv6 SID? (Yes, I thought about that and
I am kinda in favor of the idea).

Regards,
Greg

On Mon, Oct 4, 2021 at 8:10 AM James Guichard <
[email-masked]> wrote:

> Andrew,
>
>
>
> As stated in our email of September 9th, the chairs communicated that the
> working group reached rough (quite clear) consensus for standardizing one
> data plane solution to compress segment routing over IPv6. In addition to
> this there was an inclination toward using the CSID document as the basis
> for our work in this area. The chairs recognized that there was however
> disagreement as to whether this document, having multiple SRv6 EndPoint
> behaviors, could be considered consistent with the working group consensus
> for a single data plane solution. This issue quite clearly needed to be
> addressed, and the chairs, recognizing that the working group is keen to
> make progress in this area, had the option of trying to resolve the issue
> prior to issuing an adoption call, or give the working group the
> opportunity to express their opinions as part of a call for adoption.
>
>
>
> Those who feel that we need to resolve the consistency issue before
> adoption, as with those who think this is not a good basis for the WG work,
> are free and expected to object to the WG adopting the document. That is
> distinct from objecting to the chairs issuing the adoption call.
>
>
>
> In essence, the chairs have combined the question of when to resolve
> consistency and the question of whether this document is a good basis for
> the WG into one call.
>
>
>
> Yours,
>
>
>
> Jim, Bruno & Joel
>
>
>
>
>
> *From:* Andrew Alston <[email-masked]>
> *Sent:* Friday, October 1, 2021 4:21 PM
> *To:* James Guichard <[email-masked]>; SPRING WG <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: WG Adoption call for
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C5e0d0fdb84404b53517108d98519075f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687164816496052%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2BVsL9%2BHgyiQLb7%2FoAY437Vek4bhHWMrl3KdoTPbAnGU%3D&reserved=0>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C5e0d0fdb84404b53517108d98519075f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687164816506046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=67Ot32mHEqz0JXCc01%2BuI6I1WPOzrwrCTEp3rp9cVE8%3D&reserved=0>

---

From: Daniam Henriques <[email-masked]>
Date: Mon, 4 Oct 2021 15:48:19 +0000

Hi All

My foremost concern regarding the adoption to this draft relates to timing and progressing the call for adoption while there are several unaddressed and serious concerns that have been raised.

While the WG recently reached consensus around the adoption of one and only one data plane solution and we are already discussing solutions which require multiple data plane solutions, perhaps we need to consider that, while not ideal for some, having multiple data plane options provides us the best solution going forward. In this regard I believe it is important to note that all the compression mechanisms that have been proposed thus far make certain design decisions and are ultimately a compromise of flexibility, feature support, simplicity, etc. Is limiting ourselves to one and only one data-plane option the best for everyone going forward? Do we perhaps need to revisit earlier discussions around one/more data plane options before proceeding further?

I also believe Ron's point regarding RFC 4291 compliance is something that should be investigated by this WG/6MAN before adoption and not something which should only be considered later.

Regards,
Daniam
Sent: 01 October 2021 16:04

Dear WG:

Thanks!

Jim, Bruno & Joel

This email disclaimer applies to the original email, all attachments and any subsequent emails sent by Liquid Telecom. This email contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure, intended only for the named person or entity to which it is addressed. If you are not the intended recipient of this email and you received this e-mail in error, any review, use, dissemination, distribution, printing or copying of this e-mail is strictly prohibited and may be unlawful and/or an infringement of copyright. Please notify us immediately of the error and permanently delete the email from your system, retaining no copies in any media. No employee or agent is authorized to conclude any binding agreement on behalf of Liquid Telecom with another party or give any warranty by email without the express written confirmation by an authorized representative or a director of Liquid Telecom. Nothing in this email shall be construed as a legally binding agreement or warranty or an offer to contract. Liquid Telecom will not be responsible for any damages suffered by the recipient as a result of the recipient not taking cognizance of this principle. Liquid Telecom accepts no liability of whatever nature for any loss, liability, damage or expense resulting directly or indirectly from the access of any files which are attached to this message. Any email addressed to Liquid Telecom shall only be deemed to have been received once receipt is confirmed by Liquid Telecom orally or in writing. An automated acknowledgment of receipt will not suffice as proof of receipt by the Liquid Telecom. This email disclaimer shall be governed by the laws of South Africa.

---

From: Daniam Henriques <[email-masked]>
Date: Mon, 4 Oct 2021 15:27:58 +0000

Hi All

Regards,
Daniam

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 4 Oct 2021 12:19:47 -0400

+1

“If that is the case, has anyone in the WG considered that the WG may adopt
either uSID or SRv6 document as the basis of the standard compressing SRv6
SID? (Yes, I thought about that and I am kinda in favor of the idea).”

-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Mon, 4 Oct 2021 16:22:37 +0000

I support the working group adoption.

The C-SID solution described in this I-D builds on the SRv6 data plane defined in RFC 8754 and 8986 to provide a flexible, SRv6-native compression solution. It has been implemented by several vendors, with interoperability testing reported in section 11.

Furthermore, the SRComp design team analysis demonstrated that this solution meets all the compression requirements and provides the best data plane efficiency among all the evaluated solutions.

Thanks,
Francois

Thanks!

Jim, Bruno & Joel

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 4 Oct 2021 12:49:12 -0400

Dear Chairs

Was there any there any thoughts of maybe issue an adoption call for the
G-SRv6 draft itself or uSID draft itself as an option, one or the other or
separate adoption call for both drafts as they are both SRv6 compliant and
can stand on their own independently and clearly meet all the compression
requirements.

That would have taken care of the CSID 2 flavor and the one data plane
solution WG consensus dilemma call.

I think the big question is what does combining the two distinctly
different solutions from two different vendors, how that makes sense from
an POV of an operator and industry standpoint.  Unless one can benefit from
the other or if their are inter dependencies between the two that one is
not a complete solution without benefit from the other.

That is not the case here.

Kind Regards

Gyan

On Mon, Oct 4, 2021 at 11:13 AM James Guichard <
[email-masked]> wrote:

> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Friday, October 1, 2021 7:26 PM
> *To:* Tony Li <[email-masked]>
> *Cc:* Andrew Alston <Andrew.Alston=[email-masked]>;
> James Guichard <[email-masked]>; SPRING WG <
> [email-masked]>; [email-masked]
> *Subject:* Re: [spring] WG Adoption call for
> So there could be a unanimous vote to not adopt as this goes against the
> WG consensus on a single data plane solution.
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781607659%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=raeliPDdAE3XWeVOVAUVQADo0QZnB%2FFbJF53iA5M1BQ%3D&reserved=0>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781617653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xo7OrRUKD4JQtAh2%2BkojPS9ZUuooLvFAZaA6KGE0eKM%3D&reserved=0>
>
> Dear WG:
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781617653%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xo7OrRUKD4JQtAh2%2BkojPS9ZUuooLvFAZaA6KGE0eKM%3D&reserved=0> as
> the basis for its compression standardization work. That is part of what
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781627651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3sWcvuW3MBDx5N82N3fOi43DC2o2fvuIGYFQ%2Be0xpEY%3D&reserved=0> but
> with some clear guidelines as follows. By expressing support for adoption
> of this document you are fully aware of and are acknowledging that:
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781627651%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3EbeqZCC8Vu%2B8h56CW6N5Z%2BuD00N2sv%2BLzihrH7f6iE%3D&reserved=0>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781637641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k8Xzm3PKEWDd%2FEyOUEoluj3kjmThkLj7eLLlmPJqIZY%3D&reserved=0>
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781637641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fflOAQvZXQ1f3%2BCoOicSgdDv%2B7wdKCP4vcZ0hayB1BA%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Andrew Alston <[email-masked]>
Date: Mon, 4 Oct 2021 16:59:40 +0000

I would support splitting these – providing there was consensus in the working group via a separate consensus call to change the wg consensus on single solution.

I would also ask that we look closely at the working group charter in the context of each solution – because – my reading of this is that it is only uSID that runs into charter issues – as such g-srv6 could proceed on its own while agreement was requested from the relevant people as per the spring charter for uSID.  If and when such agreement is given – uSID could then be adopted as a second option in line with the consensus granted in step one if the working group feels that there is grounds for two solutions.

This at least allows us to progress without a stale mate

Andrew

From: Gyan Mishra <[email-masked]>
Date: Monday, 4 October 2021 at 19:49
To: James Guichard <[email-masked]>
Cc: Andrew Alston <[email-masked]>, SPRING WG <[email-masked]>, Tony Li <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear Chairs

Was there any there any thoughts of maybe issue an adoption call for the G-SRv6 draft itself or uSID draft itself as an option, one or the other or separate adoption call for both drafts as they are both SRv6 compliant and can stand on their own independently and clearly meet all the compression requirements.

That would have taken care of the CSID 2 flavor and the one data plane solution WG consensus dilemma call.

I think the big question is what does combining the two distinctly different solutions from two different vendors, how that makes sense from an POV of an operator and industry standpoint.  Unless one can benefit from the other or if their are inter dependencies between the two that one is not a complete solution without benefit from the other.

Kind Regards

Gyan

On Mon, Oct 4, 2021 at 11:13 AM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Hi Gyan,

Yours,

Jim, Bruno & Joel.

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: Friday, October 1, 2021 7:26 PM
To: Tony Li <[email-masked]<mailto:[email-masked]>>
Cc: Andrew Alston <Andrew.Alston=[email-masked]<mailto:[email-masked]>>; James Guichard <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression>

Dear WG chairs,

Kind Regards

Gyan

+1

Tony

Just to add to this,

Andrew

Andrew

Thanks!

Jim, Bruno & Joel

[Image removed by sender.]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C25da36500b9d45a7125008d98532dbc0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637687275781637641%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fflOAQvZXQ1f3%2BCoOicSgdDv%2B7wdKCP4vcZ0hayB1BA%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[Image removed by sender.]<http://www.verizon.com>

Gyan Mishra

M 301 502-1347

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 4 Oct 2021 17:32:01 +0000

Hi,

We all have witnessed the thorough work of the Design Team throughout the past year. They worked hard, presented their progress, asked multiple times for WG feedback, and incorporated it into their documents. As per their analysis CSID is the best compression proposal.

Additionally, for the past few years we have defined a single dataplane solution, called SRv6. It has been deployed by many operators, and a reasonable number of routing platforms support it (2021 EANTC showcased Cisco, Huawei, Juniper, and Nokia devices). RFC8986 already defines 36 different behaviors.

This document, CSID, is a single SRv6-based solution that only defines additional behaviors with the next and replace flavors.

Therefore, I support the adoption of CSID.

Regards,
Pablo.

Sent: viernes, 1 de octubre de 2021 16:05

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Dirk Steinberg <[email-masked]>
Date: Tue, 5 Oct 2021 11:47:39 +0300

Hi all,

I strongly support the adoption call for the CSID SRv6 compression proposal.

We have tested both SRv6 and CSID-based SRv6 compression in the lab
and I definitely see a lot of value in the compressed SID list option that
is provided by CSID for certain use cases.

The outstanding aspect of CSID is that it seamlessly integrates into the
SRv6 network programming framework [RFC 8986], thereby extending
the existing SRv6 dataplane in a compatible manner without introducing
a new dataplane. The proposal just introduces new endpoint flavors
within the existing framework, it is just an application of RFC 8986.

For this same reason I am not worried about the fact that two different
endpoint flavors are described in the draft, although I would expect that
eventually one variant will probably dominate real-world deployments.
This would make life easier for operators, but even if that should not turn
out to be the case it would still not be catastrophic. The network
programming
framework provides opportunity for operators to deploy the network programs
which suit their needs, and this would just be an example of this freedom of
choice and opportunity to innovate.

Cheers
Dirk

---

From: "angelo tulumello" <[email-masked]>
Date: Tue, 5 Oct 2021 16:50:55 +0200

Dear All,

I support the adoption of the CSID draft.

CSID adds the NEXT and REPLACE flavors to the END behavior but remains thoroughly coherent with the SRv6 specification described in RFC8996. As such, I think that CSID is consistent with the single SRv6 dataplane objective. 

As evidence of this, interoperability experiments have been performed involving various dataplanes (P4, eBPF, VPP, linux network stack, etc.), which show that CSID can be implemented as a single dataplane solution. Moreover, I worked on the P4 implementation and adding the support for CSID to existing SRv6 implementation has been a straightforward task, without requiring new dataplane primitives, thanks to the CSID consistency to the SRv6 specification.

Best regards,

Angelo Tulumello

Da: spring <[email-masked]> Per conto di James Guichard
Inviato: venerdì 1 ottobre 2021 16:05
A: SPRING WG <[email-masked]>
Cc: [email-masked]
Oggetto: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Kamran Raza (skraza)" <[email-masked]>
Date: Tue, 5 Oct 2021 15:11:23 +0000

I fully support the working group adoption of this doc, and would like to highlight:

  *   There are already several hardware/vendor implementations for CSID with line rate performance.

  *   As described in the section 11 of the CSID draft<https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-compression-02>, the interoperability of Next-CSID and Replace-CSID has been validated last year at China Mobile using Cisco’s ASR9000 hardware, Cisco’s XRv9000 software, and Huawei’s NE40E/N5000E hardware implementations. In this interop, the implementations were verified with a mix of Next-CSID and Replace-CSID in the same SRH.

  *   Thanks to the single SRv6 dataplane solution, the Next/Replace CSIDs work seamlessly.

Thanks,
Kamran

Date: Friday, October 1, 2021 at 10:05 AM

Thanks!

Jim, Bruno & Joel

---

From: Ron Bonica <[email-masked]>
Date: Tue, 5 Oct 2021 15:38:10 +0000

Pablo,

The WG has expressed a strong preference for having a single compression *behavior*. Why is it OK to ignore that preference because RFC 8986 has 36 different behaviors?

                                                                        Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Pablo Camarillo (pcamaril)
Sent: Monday, October 4, 2021 1:32 PM
To: James Guichard <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

RFC8986 already defines 36 different behaviors.

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 5 Oct 2021 18:57:54 +0000

Ron,

I believe your statement is wrong. The WG has expressed strong preference for a single data plane solution.

From the chairs emails:
“Given that the working group has said that it wants to standardize one data plane solution …”
“There is a rough (quite clear) consensus for standardizing one dataplane solution…”

I hope we all agree that RFC8986 is not defining 36 different dataplane solutions. 😉

Cheers,
Pablo.

From: Ron Bonica <rbonica=[email-masked]>
Sent: martes, 5 de octubre de 2021 17:38
To: Pablo Camarillo (pcamaril) <[email-masked]>; James Guichard <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Pablo,

                                                                        Ron

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Pablo Camarillo (pcamaril)

---

From: Ron Bonica <[email-masked]>
Date: Tue, 5 Oct 2021 19:42:54 +0000

Pablo,

Ae you sure? Please look at the question as Joel asked it ( https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ).

                                                                                 Ron

Juniper Business Use Only
From: Pablo Camarillo (pcamaril) <pcamaril=[email-masked]>
Sent: Tuesday, October 5, 2021 2:58 PM
To: Ron Bonica <[email-masked]>; James Guichard <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Ron,

From the chairs emails:

Cheers,
Pablo.

From: Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>
Sent: martes, 5 de octubre de 2021 17:38
To: Pablo Camarillo (pcamaril) <[email-masked]<mailto:[email-masked]>>; James Guichard <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Pablo,

                                                                        Ron

Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!XFki7y49hq-_1n9wivZdbA_IuaMQ3UTYwF-IRESDd-5OL-dV-ZwAUUkScxGGLS_d$>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Oct 2021 22:23:24 +0200

Ron & SPRING WG chairs,

Through this discussion we first have seen a debate if we need one or more
data planes to compress SIDs in SRv6. WG clearly stated we need one.

Following that we have observed a first terminology shift to see if asking
how many solutions should be supported will work any better. To that many
WG members clearly stated that they support one solution.

Well please notice that the draft in question in its introduction states:

Abstract

   This document defines a compressed SRv6 Segment List Encoding in the
   Segment Routing Header (SRH).  *This solution* does not require any SRH
   data plane change nor any SRv6 control plane change.  *This solution*
   leverages the SRv6 Network Programming model.

So based on my understanding of English the entire draft talks about a
single solution.

Then suddenly a new question popped up: how many behaviours are acceptable.

I bet number of folks including myself said "one" keeping in mind previous
discussions and the definition of "one" meaning based on the SRv6 data
plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

Interestingly enough the draft in question defines not behaviours but
flavors as new variants of the already defined behaviors in Standards Track
RFCs. Namely it defines:

4.1.  NEXT-C-SID Flavor
4.2.  REPLACE-C-SID Flavor

The newly defined behaviour End.XPS is optional.

So if there is anything to ask here is to check if WG is ok with two
flavors or not. I do not recall that question has ever been asked formally
during the WG adoption call.

With that let's note that optimal compressed SID size may be different
network to network. One size does not fit all. Draft says:

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

While I personally think 8-bit should be an option, if we choose a single
flavor we will introduce suboptimality for no good reason. Hardware
capable of supporting any flavor clearly can do LPM on locator. Also
hardware capable of supporting one flavor can support few other flavors as
this is pretty much just an offset game.

Kind regards,
Robert

On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> Pablo,
>
>
>
> Ae you sure? Please look at the question as Joel asked it (
> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/
> ).
>
>
>
>
> Ron
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 5 Oct 2021 14:36:07 -0700

Hi Robert,
as I understand it, you believe everything that is written in the draft. I
hope you can help me find an answer to one simple question:

Can a node that supports this draft in its entirety, i.e., supports all
"flavors" defined in the document, process received SRv6 packet with the
SRH encoded according to the specification?

So far, the proponents of the draft referred to "planning" how flavors of
SRv6 SID compressed. To the best of my understanding, that is is a clear
demonstration of the incompatibility between flavors defined in the CSID
draft. Regardless of what is written in it.

Regards,
Greg

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 5 Oct 2021 23:41:38 +0200

Greg,

SRH should have an equal size SIDs. That notion applies to compress SIDs.
Mixing multiple flavors in a single domain node to node seems of no use to
me. Within your domain you are subject to the domain architecture which is
the key factor what compression scheme is chosen.

Across domains (say you own N domains) the compressed SID size may vary.

Does this answer your and maybe Ron's question ?

Thx,
R.

On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky <[email-masked]> wrote:

>> Through this discussion we first have seen a debate if we need one or
>> more data planes to compress SIDs in SRv6. WG clearly stated we need one.
>>
>> Following that we have observed a first terminology shift to see if
>> asking how many solutions should be supported will work any better. To that
>> many WG members clearly stated that they support one solution.
>>
>> I bet number of folks including myself said "one" keeping in mind
>> previous discussions and the definition of "one" meaning based on the SRv6
>> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].
>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 5 Oct 2021 15:05:14 -0700

Hi Robert,
sorry,  but it doesn't seem to address my concern. My question is not about
mixing compression flavors in the same SRH (that is an interesting case of
its own). I am asking how a node that supports all the flavors defined in
the draft would parse an SRv6 packet with compressed SIDs in the SRH. The
impression I've got so far, is that is not possible for a node to process a
SID correctly without preconditions of "planning". In other words, a
controller constructs the list on the assumption that each node supports
one and only one flavor of CSID compression. Thus, I can conclude, that the
defined flavors are mutually exclusive and thus are different data plane
techniques of the SRv6 SID compression.

Regards,
Greg

On Tue, Oct 5, 2021, 14:41 Robert Raszuk <[email-masked]> wrote:

>> as I understand it, you believe everything that is written in the draft.
>> I hope you can help me find an answer to one simple question:
>>
>>> While I personally think 8-bit should be an option, if we choose a
>>> single flavor we will introduce suboptimality for no good reason. Hardware

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Oct 2021 00:07:36 +0200

To me the easiest option here is to simply configure on each node selected
compression schema for the domain. Do you see anything wrong with it ?

On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky <[email-masked]> wrote:

> Hi Robert,
> sorry,  but it doesn't seem to address my concern. My question is not
> about mixing compression flavors in the same SRH (that is an interesting
> case of its own). I am asking how a node that supports all the flavors
> defined in the draft would parse an SRv6 packet with compressed SIDs in the
> SRH. The impression I've got so far, is that is not possible for a node to
> process a SID correctly without preconditions of "planning". In other
> words, a controller constructs the list on the assumption that each node
> supports one and only one flavor of CSID compression. Thus, I can conclude,
> that the defined flavors are mutually exclusive and thus are different data
> plane techniques of the SRv6 SID compression.
>
> Regards,
> Greg
>
>>> So far, the proponents of the draft referred to "planning" how flavors
>>> of SRv6 SID compressed. To the best of my understanding, that is is a clear

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 5 Oct 2021 15:11:16 -0700

I am not asking how to deal with the fact that the mode cannot manage
different flavors using just information that is in the packet. I am
pointing that out and you are trying to avoid to acknowledge that the
problem exists. That's your choice.

Regards,
Greg

On Tue, Oct 5, 2021, 15:07 Robert Raszuk <[email-masked]> wrote:

>>> SRH should have an equal size SIDs. That notion applies to compress
>>> SIDs. Mixing multiple flavors in a single domain node to node seems of no
>>> use to me. Within your domain you are subject to the domain
>>> architecture which is the key factor what compression scheme is chosen.
>>>
>>>> as I understand it, you believe everything that is written in the
>>>> draft. I hope you can help me find an answer to one simple question:
>>>>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Oct 2021 00:17:21 +0200

That's not the case. You can map locator prefix to specific compression
schema used as an example ... This is pure implementation choice - I would
say vendor's secret sauce.

On Wed, Oct 6, 2021 at 12:11 AM Greg Mirsky <[email-masked]> wrote:

>> To me the easiest option here is to simply configure on each node
>> selected compression schema for the domain. Do you see anything wrong with
>> it ?
>>
>>>>> Can a node that supports this draft in its entirety, i.e., supports
>>>>> all "flavors" defined in the document, process received SRv6 packet with
>>>>> the SRH encoded according to the specification?
>>>>>
>>>>>> So based on my understanding of English the entire draft talks about
>>>>>> a single solution.
>>>>>>
>>>>>> With that let's note that optimal compressed SID size may be
>>>>>> different network to network. One size does not fit all. Draft says:
>>>>>>
>>>>>> 6.1.  C-SID Length
>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 5 Oct 2021 15:20:15 -0700

"Secret sauce" is another way to say not-interoperable. And that is exactly
the point I am making.

Regards,
Greg

On Tue, Oct 5, 2021, 15:17 Robert Raszuk <[email-masked]> wrote:

>>>>>> So far, the proponents of the draft referred to "planning" how
>>>>>> flavors of SRv6 SID compressed. To the best of my understanding, that is is
>>>>>> a clear demonstration of the incompatibility between flavors defined in the
>>>>>> CSID draft. Regardless of what is written in it.
>>>>>>
>>>>>> Regards,
>>>>>> Greg
>>>>>>
>>>>>>> Through this discussion we first have seen a debate if we need one
>>>>>>> or more data planes to compress SIDs in SRv6. WG clearly stated we need
>>>>>>> one.
>>>>>>>
>>>>>>> Interestingly enough the draft in question defines not behaviours
>>>>>>> but flavors as new variants of the already defined behaviors in Standards
>>>>>>> Track RFCs. Namely it defines:
>>>>>>>
>>>>>>> 4.1.  NEXT-C-SID Flavor

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 6 Oct 2021 00:39:47 +0200

Greg,

When you receive any packet you do a LPM on the dst address. The result of
that lookup reveals the secret on how to handle the packet further.

What is non-interoperable here ? I see You would love to have a few bits
next to the locator prefix to specify verbatim what to do with the packet ?
What for ? To run out of those bits in no time and make a mess ?

On Wed, Oct 6, 2021 at 12:20 AM Greg Mirsky <[email-masked]> wrote:

> "Secret sauce" is another way to say not-interoperable. And that is
> exactly the point I am making.
>
> Regards,
> Greg
>
>>>>>>>> So based on my understanding of English the entire draft talks
>>>>>>>> about a single solution.
>>>>>>>>
>>>>>>>> So if there is anything to ask here is to check if WG is ok with
>>>>>>>> two flavors or not. I do not recall that question has ever been asked
>>>>>>>> formally during the WG adoption call.
>>>>>>>>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 5 Oct 2021 16:23:34 -0700

Hi Robert,
that is a more elegant way to mitigate the problem. But the fact that you
need to use the control or management plane to disseminate the mapping
between the particular flavor and corresponding prefix still tells me that
in the data plane these flavors are distinct and incompatible entities,
i.e., different data plane solutions to the SRv6 SID compression.

Regards,
Greg

On Tue, Oct 5, 2021 at 3:39 PM Robert Raszuk <[email-masked]> wrote:

>>>>>>>>> Following that we have observed a first terminology shift to see
>>>>>>>>> if asking how many solutions should be supported will work any better. To
>>>>>>>>> that many WG members clearly stated that they support one solution.
>>>>>>>>>

---

From: Ahmed Bashandy <[email-masked]>
Date: Tue, 5 Oct 2021 19:53:07 -0700

* The network programming model (RFC8986) defines multiple behaviors,
    CSID is just adding the next and replace flavors
  * The draft proposes a single SRv6 based data plane that defines next
    and replace behaviors. IMO that is consistent with RFC8986

  * CSID has been recommended by the design team for SRv6 based compression
  * Interop was done. That is more evidence that CSID is a single data
    plane solution
  * IMO CSID is ready to become the basis for the SRv6 compression solution
  * Being an SRv6 data plane-based solution, CSID is coherent with the
    one data plane solution objective
  * CSID meets SRv6 compression requirements as single solution

Thanks

Ahmed

On 10/1/21 7:04 AM, James Guichard wrote:
>
> 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.
>
> <https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/> 
> Because of the above the chairs would like to issue a 2-week WG call 
> for adoption ending October 15^th for 
> <https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/> 
>     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.
>     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
>
>

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 6 Oct 2021 03:57:32 +0000

Adding to this Robert, indeed SRv6 defines many behaviors.  The question asked about a single ‘behavior’ could really only be interpreted as asking about single ‘solution’, as you understood, since a single ‘behavior’ in SRv6 is non-sensical.  The requirements draft section 4.2 alone requires multiple behaviors be supported, and multiple compression levels in 4.4.4.

Darren

On 2021-10-05, 4:24 PM, "spring" <[email-masked]> wrote:

Ron & SPRING WG chairs,

Through this discussion we first have seen a debate if we need one or more data planes to compress SIDs in SRv6. WG clearly stated we need one.

Following that we have observed a first terminology shift to see if asking how many solutions should be supported will work any better. To that many WG members clearly stated that they support one solution.

Abstract

   This document defines a compressed SRv6 Segment List Encoding in the
   Segment Routing Header (SRH).  This solution does not require any SRH
   data plane change nor any SRv6 control plane change.  This solution
   leverages the SRv6 Network Programming model.

So based on my understanding of English the entire draft talks about a single solution.

I bet number of folks including myself said "one" keeping in mind previous discussions and the definition of "one" meaning based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

Interestingly enough the draft in question defines not behaviours but flavors as new variants of the already defined behaviors in Standards Track RFCs. Namely it defines:

4.1.  NEXT-C-SID Flavor

So if there is anything to ask here is to check if WG is ok with two flavors or not. I do not recall that question has ever been asked formally during the WG adoption call.

With that let's note that optimal compressed SID size may be different network to network. One size does not fit all. Draft says:

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.

While I personally think 8-bit should be an option, if we choose a single flavor we will introduce suboptimality for no good reason. Hardware capable of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can support few other flavors as this is pretty much just an offset game.

Kind regards,
Robert

On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>> wrote:
Pablo,

                                                                                 Ron

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 6 Oct 2021 04:30:04 +0000

I support the WG adoption of this draft.

I’ve spent a year and a half with the design team studying requirements and analyzing all solutions to SRv6 SID list compression with multiple WG reviews and many hours of work.  The CSID proposal is the strongest, and fully based on the SRv6 data plane.

Combined with the breadth of contributors, implementations and deployments it makes a very good solution for the working group to adopt and progress.  I am certain there will be no shortage of interest nor energy to complete it.

Sincerely
  Darren

On 2021-10-01, 10:05 AM, "spring" <[email-masked]> wrote:

Dear WG:

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

---

From: Antonio Cianfrani <[email-masked]>
Date: Wed, 6 Oct 2021 10:47:16 +0200

I support the WG adoption of the CSID draft.
I understand that CSID draft defines multiple SRv6 behaviors, but they are
based on a single SRv6 data plane solution.
Kind regards,
Antonio Cianfrani

Il giorno mer 6 ott 2021 alle ore 06:30 Darren Dukes (ddukes) <ddukes=
[email-masked]> ha scritto:

> I’ve spent a year and a half with the design team studying requirements
> and analyzing all solutions to SRv6 SID list compression with multiple WG
> reviews and many hours of work.  The CSID proposal is the strongest, and
> fully based on the SRv6 data plane.
>
>
>
> Combined with the breadth of contributors, implementations and deployments
> it makes a very good solution for the working group to adopt and progress.
> I am certain there will be no shortage of interest nor energy to complete
> it.
>
>
>
> Sincerely
>
>   Darren
>
>
>
>
>
> ·         "Given that the working group has said that it wants to

-- 
________________________________________________________
Le informazioni 
contenute in questo messaggio di posta elettronica sono strettamente 
riservate e indirizzate esclusivamente al destinatario. Si prega di non 
leggere, fare copia, inoltrare a terzi o conservare tale messaggio se non 
si è il legittimo destinatario dello stesso. Qualora tale messaggio sia 
stato ricevuto per errore, si prega di restituirlo al mittente e di 
cancellarlo permanentemente dal proprio computer.
The information contained 
in this e mail message is strictly confidential and intended for the use of 
the addressee only.  If you are not the intended recipient, please do not 
read, copy, forward or store it on your computer. If you have received the 
message in error, please forward it back to the sender and delete it 
permanently from your computer system.

-- 

Fai crescere i nostri giovani ricercatori
dona il 5 per mille alla 
Sapienza
*codice fiscale 80209930587*

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 6 Oct 2021 08:49:26 +0000

I strongly object to the adoption of the draft.

There are 3 different flavors defined in the draft
and all three flavors have significant difference in
the forwarding plane behaviours.

I would prefer the discussion on whether WG wants to work on
all these flavors or only one of them to
precede the adoption.

Rgds
Shraddha

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Ron Bonica
Sent: Friday, October 1, 2021 11:37 PM
To: James Guichard <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Chairs,

                                                                                                              Ron

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of James Guichard

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Wed, 6 Oct 2021 14:04:52 +0000

Hi Greg,

A node that supports this draft in its entirety can instantiate SRv6 SIDs (e.g., End and End.X SIDs) with any of the three C-SID flavors.

In particular, a node can instantiate multiple SRv6 SIDs bound to different C-SID flavors, possibly with different C-SID lengths. It can also instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.

As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, upon receiving an IPv6 packet with a destination address matching a FIB entry that represents one of these locally instantiated SIDs, the node processes the packet according to the behavior (and flavor(s)) (i.e. pseudocode) of that SID.

RFC 8754 and 8986 have already standardized these mechanisms and the C-SID draft only leverages the same SRv6 dataplane to introduce new endpoint flavors for compression.

Francois

From: spring <[email-masked]> on behalf of Greg Mirsky <[email-masked]>
Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk <[email-masked]>
Cc: Ron Bonica <rbonica=[email-masked]>, James Guichard <[email-masked]>, SPRING WG <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Robert,
as I understand it, you believe everything that is written in the draft. I hope you can help me find an answer to one simple question:
Can a node that supports this draft in its entirety, i.e., supports all "flavors" defined in the document, process received SRv6 packet with the SRH encoded according to the specification?
So far, the proponents of the draft referred to "planning" how flavors of SRv6 SID compressed. To the best of my understanding, that is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of what is written in it.

Regards,
Greg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Ron & SPRING WG chairs,

Abstract

4.1.  NEXT-C-SID Flavor

6.1.  C-SID Length

Kind regards,
Robert

                                                                                 Ron

---

From: Ron Bonica <[email-masked]>
Date: Wed, 6 Oct 2021 16:06:25 +0000

Ahmed,

I don't recall the DT recommending the CSID. In fact, the word "recommend" does not appear anywhere in the analysis document.

As a member of the DT, I don't recommend CSID.

                                                                           Ron

Juniper Business Use Only
From: spring <[email-masked]> On Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

  *   The network programming model (RFC8986) defines multiple behaviors, CSID is just adding the next and replace flavors
  *   The draft proposes a single SRv6 based data plane that defines next and replace behaviors. IMO that is consistent with RFC8986

  *   CSID has been recommended by the design team for SRv6 based compression
  *   Interop was done. That is more evidence that CSID is a single data plane solution
  *   IMO CSID is ready to become the basis for the SRv6 compression solution
  *   Being an SRv6 data plane-based solution, CSID is coherent with the one data plane solution objective
  *   CSID meets SRv6 compression requirements as single solution

Thanks

Ahmed

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!UB-06E0vV1hJFKLsWYZym6F3d_lXgEa-0TT6vPXh5GKmmrA9UhFLCWIRgLQM66Td$> 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!UB-06E0vV1hJFKLsWYZym6F3d_lXgEa-0TT6vPXh5GKmmrA9UhFLCWIRgLQM66Td$> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

spring mailing list

https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UB-06E0vV1hJFKLsWYZym6F3d_lXgEa-0TT6vPXh5GKmmrA9UhFLCWIRgDaeqmAm$>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 6 Oct 2021 10:19:14 -0700

Hi Francois,
thank you for the clarification. It is still not clear how a node selects
which flavor of CSID to use on the next compressed CSID that may happen
also be in the next CSID container. As I understand it, a CSID container
must use the same flavor of compression but CSID containers with different
compression flavors in the same SRH are allowed. Is that correct
understanding?

Regards,
Greg

On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) <[email-masked]>
wrote:

> Hi Greg,
>
>
>
> A node that supports this draft in its entirety can instantiate SRv6 SIDs
> (e.g., End and End.X SIDs) with any of the three C-SID flavors.
>
>
>
> In particular, a node can instantiate multiple SRv6 SIDs bound to
> different C-SID flavors, possibly with different C-SID lengths. It can also
> instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.
>
>
>
> As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986,
> upon receiving an IPv6 packet with a destination address matching a FIB
> entry that represents one of these locally instantiated SIDs, the node
> processes the packet according to the behavior (and flavor(s)) (i.e.
> pseudocode) of that SID.
>
>
>
> RFC 8754 and 8986 have already standardized these mechanisms and the C-SID
> draft only leverages the same SRv6 dataplane to introduce new endpoint
> flavors for compression.
>
>
>
>
>
> Francois
>
>
>
> *From: *spring <[email-masked]> on behalf of Greg Mirsky <
> [email-masked]>
> *Date: *Tuesday, 5 October 2021 at 23:37
> *To: *Robert Raszuk <[email-masked]>
> *Cc: *Ron Bonica <rbonica=[email-masked]>, James Guichard <
> [email-masked]>, SPRING WG <[email-masked]>,
> [email-masked] <[email-masked]>
> *Subject: *Re: [spring] WG Adoption call for

---

From: Ahmed Bashandy <[email-masked]>
Date: Wed, 6 Oct 2021 10:20:47 -0700

If we take a look at the summary table in slide 17 in the DT 
presentation at last IETF

https://datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp-design-team-update-00

wecan see that CSID is the only column with *all blocks dark green*.

Thanks

Ahmed

On 10/6/21 9:06 AM, Ron Bonica wrote:
>
> Ahmed,
>
> I don’t recall the DT recommending the CSID. In fact, the word 
> “recommend” does not appear anywhere in the analysis document.
>
> As a member of the DT, I don’t recommend CSID.
>
>             Ron
>
> *From:* spring <[email-masked]> *On Behalf Of *Ahmed Bashandy
> *Sent:* Tuesday, October 5, 2021 10:53 PM
> *To:* James Guichard <[email-masked]>; SPRING WG 
> <[email-masked]>
> *[External Email. Be cautious of content]*
>
>   * The network programming model (RFC8986) defines multiple
>     behaviors, CSID is just adding the next and replace flavors
>   * The draft proposes a single SRv6 based data plane that defines
>     next and replace behaviors. IMO that is consistent with RFC8986
>
>     <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!UB-06E0vV1hJFKLsWYZym6F3d_lXgEa-0TT6vPXh5GKmmrA9UhFLCWIRgLQM66Td$>
>     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 15^th for
>     <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!UB-06E0vV1hJFKLsWYZym6F3d_lXgEa-0TT6vPXh5GKmmrA9UhFLCWIRgLQM66Td$>
>     but with some clear guidelines as follows. By expressing support
>     for adoption of this document you are fully aware of and are
>     acknowledging that:
>
>         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.
>          1. "Given that the working group has said that it wants to
>             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.".
>
>     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
>
>     [email-masked]  <mailto:[email-masked]>
>
>     https://www.ietf.org/mailman/listinfo/spring  <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!UB-06E0vV1hJFKLsWYZym6F3d_lXgEa-0TT6vPXh5GKmmrA9UhFLCWIRgDaeqmAm$>
>

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Wed, 6 Oct 2021 17:29:04 +0000

Hi,

I support this document for WG adoption, based on the results of the analysis draft.

Thanks.
Jorge

Date: Friday, October 1, 2021 at 4:05 PM

Thanks!

Jim, Bruno & Joel

---

From: Stefano Salsano <[email-masked]>
Date: Wed, 6 Oct 2021 20:26:01 +0200

Hi,

I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression

the draft is compliant with the RFC 8986 and adds two new flavors to the 
End behavior

with my research team, I've been working on the design and 
implementation of the SRv6 network programming model (RFC 8986) on the 
Linux OS, we're currently implementing the framework to support the 
flavors defined in RFC 8986

from our point of view, the two new flavors clearly belong to the same 
SRv6 dataplane and can be implemented "side by side" in the SRv6 Linux 
implementation

ciao
Stefano

Il 2021-10-01 16:04, James Guichard ha scritto:
> responses received to our emails with reference to how the working group 
> wishes to move forward with respect to a solution for SRv6 compression.
> 
> adoption ending October 15^th for 
>     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:
>         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.".
> 

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Thu, 7 Oct 2021 16:17:09 +0000

Hi Greg,

It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the segment list in the SRH. It learns about the available SIDs in the network with their associated behavior and flavors via control plane and/or management plane protocols, as described in Section 8 of RFC 8986, and selects the SIDs that are the most appropriate for the segment list.

Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes the pseudocode of a locally instantiated SID when it receives a packet matching that SID. The SR Segment Endpoint Node does not need to bother about the behavior/flavor of the subsequent SRv6 SIDs.

This SRv6 logic applies to the C-SID flavors as well. The choice of flavors for the SIDs in the SID List is up to the SR Source Node.

It is indeed possible to mix SIDs of different C-SID flavors in the same SRH, and even in a single C-SID container.

Thanks,
Francois

From: Greg Mirsky <[email-masked]>
Date: Wednesday, 6 October 2021 at 19:19
To: Francois Clad (fclad) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, James Guichard <[email-masked]>, SPRING WG <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Francois,
thank you for the clarification. It is still not clear how a node selects which flavor of CSID to use on the next compressed CSID that may happen also be in the next CSID container. As I understand it, a CSID container must use the same flavor of compression but CSID containers with different compression flavors in the same SRH are allowed. Is that correct understanding?

Regards,
Greg

On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Francois

From: spring <[email-masked]<mailto:[email-masked]>> on behalf of Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Cc: Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>, James Guichard <[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Robert,
as I understand it, you believe everything that is written in the draft. I hope you can help me find an answer to one simple question:
Can a node that supports this draft in its entirety, i.e., supports all "flavors" defined in the document, process received SRv6 packet with the SRH encoded according to the specification?
So far, the proponents of the draft referred to "planning" how flavors of SRv6 SID compressed. To the best of my understanding, that is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of what is written in it.

Regards,
Greg

Abstract

4.1.  NEXT-C-SID Flavor

6.1.  C-SID Length

Kind regards,
Robert

                                                                                 Ron

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 Oct 2021 17:28:40 +0000

Folks,

We appear to dancing around the meaning of the words "solution", "behavior", and "flavor".  While this dance is semantically elegant, it is neither productive nor uplifting.

A better way to determine whether NEXT-C-SID and REPLACE-C-SID are both needed is with a tiny bit more analysis. Specifically:

  *   Determine whether NEXT-C-SID and a REPLACE-C-SID yield the same compression efficiency. That is, update Table 12 through 15 in the analysis document, replacing the CSID column with a CSID NEXT-C-SID and a CSID REPLACE-C-SID column.
  *   Determine whether NEXT-C-SID and a REPLACE-C-SID are compatible with one another. That is, provide an example where an SR path contains 8 segments. Odd numbered segments use NEXT-C-SID and even numbered segments use REPLACE-C-SID. What does the packet look like when it arrives at the first segment. How does it change at each subsequent segments. (Yes, I know that you recommend against doing this for "operational simplicity". But we aren't trying to determine if it is simple. We are trying to determine if NEXT-C-SID and a REPLACE-C-SID work well together at all.)
  *   Determine whether both are needed. That is, describe a use case where one works well and another does not.

I think that this will be much more productive than arguing about "flavors". That is, unless the flavor is "pumpkin spice".

                                                                                                                 Ron

Juniper Business Use Only
From: Darren Dukes (ddukes) <ddukes=[email-masked]>
Sent: Tuesday, October 5, 2021 11:58 PM
To: Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>
Cc: James Guichard <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Adding to this Robert, indeed SRv6 defines many behaviors.  The question asked about a single 'behavior' could really only be interpreted as asking about single 'solution', as you understood, since a single 'behavior' in SRv6 is non-sensical.  The requirements draft section 4.2 alone requires multiple behaviors be supported, and multiple compression levels in 4.4.4.

Darren

On 2021-10-05, 4:24 PM, "spring" <[email-masked]<mailto:[email-masked]>> wrote:

Ron & SPRING WG chairs,

Abstract

4.1.  NEXT-C-SID Flavor

6.1.  C-SID Length

Kind regards,
Robert

Ae you sure? Please look at the question as Joel asked it ( https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/__;!!NEt6yMaO-gk!SJ05xMMUQP04gjOLjvjfnHc9s-g4_SlxXHnM2QzJtLZoAQhHpySsp2ZWQ7k9cvUw$> ).

                                                                                 Ron

---

From: Ron Bonica <[email-masked]>
Date: Thu, 7 Oct 2021 17:41:07 +0000

Ahmed,

That is a far cry from recommending anything.

  *   If you take a look at the first page of that slide deck, the DT was tasked with enumeration and analysis of requirements. The word "recommend" does not appear on that page.
  *   If you look at the third page of that slide deck, you will see that one very important requirement (PS/BCP Compliance) was left for the relevant WGs to determine.
  *   If you look under the chart, you will see a note that says "All requirements are not equally important. The working group must decide which are more significant." The WG needs to determine whether the requirements that register a difference are significant.

                                                                       Ron

Juniper Business Use Only
From: Ahmed Bashandy <[email-masked]>
Sent: Wednesday, October 6, 2021 1:21 PM
To: Ron Bonica <[email-masked]>; James Guichard <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

If we take a look at the summary table in slide 17 in  the DT presentation at last IETF

https://datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp-design-team-update-00<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp-design-team-update-00__;!!NEt6yMaO-gk!XRu-vlE4UU8DQXBtTSicMvItj5PBLG69P1RlwJSbtBR6lOLQtnSPeds1ommxXiJY$>

we can see that CSID is the only column with *all blocks dark green*.

Thanks

Ahmed

                                                                           Ron

Juniper Business Use Only
From: spring <[email-masked]><mailto:[email-masked]> On Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard <[email-masked]><mailto:[email-masked]>; SPRING WG <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!XRu-vlE4UU8DQXBtTSicMvItj5PBLG69P1RlwJSbtBR6lOLQtnSPeds1ovJ2hhnQ$>

  1.  The network programming model (RFC8986) defines multiple behaviors, CSID is just adding the next and replace flavors
  2.  The draft proposes a single SRv6 based data plane that defines next and replace behaviors. IMO that is consistent with RFC8986

  1.  CSID has been recommended by the design team for SRv6 based compression
  2.  Interop was done. That is more evidence that CSID is a single data plane solution
  3.  IMO CSID is ready to become the basis for the SRv6 compression solution
  4.  Being an SRv6 data plane-based solution, CSID is coherent with the one data plane solution objective
  5.  CSID meets SRv6 compression requirements as single solution

Thanks

Ahmed

Thanks!

Jim, Bruno & Joel

spring mailing list

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 7 Oct 2021 11:15:19 -0700

Hi Francois,
thank you for your detailed response and confirming that C-SIDs of
different flavors/behavior may be present in the same SRH and even the same
CSID container. I've noticed Ron's proposal as I was trying to formulate my
question. His proposal highlighted what I am trying to understand - the
relationship between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The
WG has adopted the compression analysis draft
<https://datatracker.ietf.org/doc/draft-ietf-spring-compression-analysis/>,
and the updates and an additional analysis Ron proposed will keep the
discussion and decision-making process on the firm technical foundation.

Regards,
Greg

On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) <[email-masked]>
wrote:

> Hi Greg,
>
>
>
> It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the
> segment list in the SRH. It learns about the available SIDs in the network
> with their associated behavior and flavors via control plane and/or
> management plane protocols, as described in Section 8 of RFC 8986, and
> selects the SIDs that are the most appropriate for the segment list.
>
>
>
> Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes
> the pseudocode of a locally instantiated SID when it receives a packet
> matching that SID. The SR Segment Endpoint Node does not need to bother
> about the behavior/flavor of the subsequent SRv6 SIDs.
>
>
>
> This SRv6 logic applies to the C-SID flavors as well. The choice of
> flavors for the SIDs in the SID List is up to the SR Source Node.
>
>
>
> It is indeed possible to mix SIDs of different C-SID flavors in the same
> SRH, and even in a single C-SID container.
>
>
>
> Thanks,
>
> Francois
>
>
>
>
>
> *From: *Greg Mirsky <[email-masked]>
> *Date: *Wednesday, 6 October 2021 at 19:19
> *To: *Francois Clad (fclad) <[email-masked]>
> *Cc: *Robert Raszuk <[email-masked]>, Ron Bonica <rbonica=
> [email-masked]>, James Guichard <

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 7 Oct 2021 12:46:46 -0700

I object to the adoption of this document as it currently stands.

:K

> On Oct 1, 2021, at 07:04, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>  
> Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ <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:
>  
> https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>

---

From: Colby Barth <[email-masked]>
Date: Thu, 7 Oct 2021 15:55:20 -0400

I object to the adoption of this document in its current form.

—Colby

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 7 Oct 2021 12:55:31 -0700

I also object to WG chairs who are also co-authors of a draft participating in the process of advancing the draft through the WG process, whether it is WG adoption, WGLC or IETF LC.

Look up “recuse” in the dictionary.

:K

---

From: "Rakesh Gandhi (rgandhi)" <[email-masked]>
Date: Thu, 7 Oct 2021 20:19:28 +0000

Hi Chairs, WG,

Network programming model [RFC8986] defines multiple flavors of End, End.X, and End.T SIDs. CSID draft builds on it with next and replace flavors for these SIDs. The draft reports multivendor interop was done to show co-existence of next and replace flavors. This is evidence that these flavors work seamless using SRH based single data plane.

I strongly support the adoption call.

Thanks,
Rakesh

Da: spring <[email-masked]> James Guichard

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Tarek Saad <[email-masked]>
Date: Fri, 8 Oct 2021 04:04:42 +0000

Hi all,

I’ve read this draft. It is proposing 2 different encodings schemes for compressed sequence of SRv6 SIDs (and an optional behavior on border nodes)..
Although Section 4 makes a claim that different deployments usecase may deem one encoding scheme superior over the other, I could not glean in which cases a scheme would outperform the other and why? Or, why is the WG trying to standardize both the two flavors -- keeping in mind the complex HW procedures evident by the proposed different pseudo codes in the draft.

Also, are there concerns of misinterpreting (wrongfully decoding) a GSID sequence for a C-SID-sequence (or vice-versa) for a received packet on border nodes that may support both encoding flavors simultaneously?

For these reasons, I think this it is still premature for this draft to be adopted, and I oppose its adoption.

Regards,
Tarek

Thanks!

Jim, Bruno & Joel

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 8 Oct 2021 18:02:21 +0800

Dear Chairs & WG，

I believe two flavors are better for operators:
- Interoperation between both flavors has been verified in China Mobile Lab, and it works very well.
- As an operator I want flexibility to choose different flavors in deployment. 

It makes sense that operators have the ability to choose when to instantiate these SIDs to achieve their different goals.

Best Regards，
Liyan Gong
 
From: James Guichard
Date: 2021-10-01 22:04
To: SPRING WG
CC: [email-masked]
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Dear WG:

 

 
Thanks!
 
Jim, Bruno & Joel

---

From: "Sales, Bernard (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 8 Oct 2021 11:02:59 +0000

Hello,

I support the adoption of https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/.

Many Thanks,

-- Brd

Sent: Friday, October 1, 2021 4:05 PM

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Giulio Sidoretti <[email-masked]>
Date: Fri, 8 Oct 2021 14:59:55 +0200

Hi WG, WG chairs,

I support the WG adoption of the draft.

I have been working with SRv6 as part of my PhD. My team focuses on SRv6 implementation in Linux and other open source stacks like VPP, eBPF and others. The CSID draft is compliant with RFC 8986. We read the documents from the design team (DT) and we understand the benefit of the flavours defined in the CSID draft for different deployments.

Kind regards,
Giulio Sidoretti

> On 1 Oct 2021, at 16:04, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>  
> Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15thfor https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ <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: 
>

---

From: Martin Horneffer <[email-masked]>
Date: Fri, 8 Oct 2021 16:29:15 +0200

Hello everyone,

as I see it, the document fits well into the framework of RFC8986, it 
solved the problem, and does so in an efficient manner. Thus I support 
the adoption of this document.

Best rergards, Martin

---

From: Andrew Alston <[email-masked]>
Date: Fri, 8 Oct 2021 15:22:58 +0000

Figured I would weigh in here once again - and try and summarize the way I see things.

  1.  The working group found consensus on a single behavior - this document contains 3 - if that consensus is to be changed - let it be changed by the working group before we walk down this path.
  2.  The charter of the spring working group is very clear - it states:

Any modification of -or extension to- existing architectures, data planes, or control or management plane protocols should be carried out in the WGs responsible for the architecture, data plane, or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in SPRING WG after agreement with all the relevant WG chairs and responsible area directors.
              I have yet to see each agreement voiced by these parties.

  1.  There is technical dispute over the overloading of addresses and the use of IPv6 addresses in this manner, and if the excuse of limited domain is valid to get away with this - this has not been resolved
  2.  Two out of the three working group chairs who are actively involved in calling for the adoption of this document are co-authors of said document and have not recused themselves and stated they will not take part in decisions regarding its progression - the term - conflict of interest - was created for such situations
  3.  There have been suggestions on this list about splitting g-srv6 out - so that it can proceed, since it does NOT seem to run afoul of (B) and then if the working group sees fit to agree to change the view on single behavior, the csid parts could be processed separately should the chairs and ad's involved in the INT group agree - this suggestion has never had a full response or a reason why this is either impractical or should not go ahead - and under the definition of rough consensus therefore stands as an unaddressed issued.

I am kinda shocked in a situation where almost any one of these points would be sufficient to act as a blocker - we are still walking down this path - I lament the lack of adherence to the bottom up approach that I am seeing here, and the disregard shown towards clear conflicts of interest, particularly where there are scenarios under which we could all progress that would resolve half of the issues above.

Let us act in a way that is in adherence to the bottom-up approach, respects working group consensus, avoids conflicts of interest, follows the charter and eventually ends up in a place where distrust in the process is allowed to fester.

Thanks

Andrew

Sent: Friday, October 1, 2021 5:05 PM

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: James Guichard <[email-masked]>
Date: Fri, 8 Oct 2021 16:15:11 +0000

Andrew,

To your point D and in response to others that have expressed the same concern.

The chairs have already discussed this and are very aware of, and will conform to, IETF process. As a co-author of the document in question I will of course recuse myself from the decision process for adoption of the document into the working group. This was never in question but let me make that point very clear now so that there is no further confusion or concern that the chairs will not follow standard procedures.

Jim

Sent: Friday, October 8, 2021 11:23 AM

Thanks

Andrew

Dear WG:

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Cd73ddcb23a224377961208d98a6f85d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637693033882878589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qVc1JtbYU0DHrh6XcbfMARecW8yLiL05zpsx1itMk2o%3D&reserved=0> 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7Cd73ddcb23a224377961208d98a6f85d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637693033882888583%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g%2FGrcz5fBZwMzF9dCU1GE%2BuuY3HBu%2BhUvRCsQmUuJFk%3D&reserved=0> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

---

From: <[email-masked]>
Date: Fri, 8 Oct 2021 16:16:49 +0000

Kireeti, all,

Being a co-author of draft-filsfilscheng-spring-srv6-srh-compression, I recuse myself from assessing the WG consensus on this document.

--Bruno

Orange Restricted
From: spring <[email-masked]> On Behalf Of Kireeti Kompella
Sent: Thursday, October 7, 2021 9:56 PM
To: James Guichard <[email-masked]>
Cc: Kireeti Kompella <[email-masked]>; SPRING WG <[email-masked]>; [email-masked]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Look up "recuse" in the dictionary.

:K

On Oct 1, 2021, at 07:04, James Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th forhttps://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:

Thanks!

Jim, Bruno & Joel

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Melchior Aelmans <[email-masked]>
Date: Fri, 8 Oct 2021 18:22:52 +0200

Agree with the objection. I don't see how this can progress in the current
state and situation and decisions in this WG being made earlier on this.

Thanks,
Melchior

---

From: "苏远超(以泰)" <[email-masked]>
Date: Sat, 09 Oct 2021 00:52:56 +0800

Hi Dear WG，
    I support the adoption of this draft.
    Both next and replace flavors are consistent with the SRv6 network programming(RFC 8986)and uses SRH based data plane(RFC 8754), therefore I don't consider these two flavors are two solutions but flexibilities for different scenarios. 
    Proceeding with CSID would help create a robust eco-system which we could leverage.
    Thanks.

          Yuanchao Su
          AliCloud Network Director
 
------------------------------------------------------------------
发件人：James Guichard <[email-masked]>
发送时间：2021年10月1日(星期五) 22:05
收件人：SPRING WG <[email-masked]>
抄　送：[email-masked] <[email-masked]>
主　题：[spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

---

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

Hi Greg,

Thank you for the confirmation. I am glad that the matter of combining C-SIDs of different flavors is clear now.

Thanks,
Francois

From: Greg Mirsky <[email-masked]>
Date: Thursday, 7 October 2021 at 20:15
To: Francois Clad (fclad) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, James Guichard <[email-masked]>, SPRING WG <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Francois,
thank you for your detailed response and confirming that C-SIDs of different flavors/behavior may be present in the same SRH and even the same CSID container. I've noticed Ron's proposal as I was trying to formulate my question. His proposal highlighted what I am trying to understand - the relationship between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG has adopted the compression analysis draft<https://datatracker.ietf.org/doc/draft-ietf-spring-compression-analysis/>, and the updates and an additional analysis Ron proposed will keep the discussion and decision-making process on the firm technical foundation.

Regards,
Greg

On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Francois

From: Greg Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 6 October 2021 at 19:19
To: Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>>
Cc: Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Ron Bonica <rbonica=[email-masked]<mailto:[email-masked]>>, James Guichard <[email-masked]<mailto:[email-masked]>>, SPRING WG <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Francois,
thank you for the clarification. It is still not clear how a node selects which flavor of CSID to use on the next compressed CSID that may happen also be in the next CSID container. As I understand it, a CSID container must use the same flavor of compression but CSID containers with different compression flavors in the same SRH are allowed. Is that correct understanding?

Regards,
Greg

Francois

Regards,
Greg

Abstract

4.1.  NEXT-C-SID Flavor

6.1.  C-SID Length

Kind regards,
Robert

                                                                                 Ron

---

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

Hi Tarek,

I am assuming that the border node is an SR segment endpoint node in your question.

This node processes the packet according to the behavior bound to the locally instantiated SID that was matched (see Section 4.3 of RFC 8754). There is no interpretation required.

It is the responsibility of the SR source to make sure that the SIDs in the Segment-List are used appropriately. This applies to all SRv6 SIDs, including those defined in RFC 8986. It is the same as ensuring that there is not an End.DT4 SID in the middle of the Segment-List or that an End.X SID bound to the right interface is used.

Thanks,
Francois

From: spring <[email-masked]> on behalf of Tarek Saad <[email-masked]>
Date: Friday, 8 October 2021 at 06:06
To: James Guichard <[email-masked]>, SPRING WG <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi all,

Regards,
Tarek

Thanks!

Jim, Bruno & Joel

---

From: Parag Kaneriya <[email-masked]>
Date: Fri, 8 Oct 2021 18:05:29 +0000

I object the adoption of this document

-Parag

Sent: Friday, October 1, 2021 7:35 PM

Dear WG:

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!XVBiEu1HysG880P_LdgU51k65vuwtIHLH5R_wHdeZ4uHuEXIhHvhAli5qhMPQRGv$> 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!XVBiEu1HysG880P_LdgU51k65vuwtIHLH5R_wHdeZ4uHuEXIhHvhAli5qhMPQRGv$> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 8 Oct 2021 13:21:12 -0700

Hi Francois,
you've said that different flavors of C-SID can be present not only in the
same SRH but also in the same C-SID container. The latter case got me
thinking about several potential scenarios. Have to admit that I got stuck
trying to understand how they can work. I hope you can help me out. Please
consider the two cases described below.

Consider, for all cases, that we are handling a container with entries A,
B, C, and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors.

Case 1:
Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID
flavor. When A is processed, B will be copied into the IPv6 DA, retaining
the prefix before A in the container. So far, so good. Then, when the
packet arrives at the node that processes B, it will say "NEXT". The
remaining bits will be? I thought zero, but actually, it will presumably be
two bits with the value two? So the subsequent behavior will shift that two
up? Even if the NEXT-C-SID flavor guesses that the two should be zero, it
would skip C and D and pick up the entry from the next C-SID container in
the SRH. So it seems to either work wrong or work oddly?

Case 2:
Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D
upwards in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will
interpret the upper bits of the C C-SID as the arg for selecting the
position in the C-SID container to pull an entry from. It will also modify
the C C-SID to perform the decrement it thinks it needs. It will then
overwrite itself with the randomly chosen entry from the container.

It seems that neither scenario works. At least, I cannot figure out how it
can work. I would greatly appreciate it if you could have a look and
clarify it for me.
Regards,
Greg

On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad) <[email-masked]>
wrote:

> Hi Greg,
>
>
>
> Thank you for the confirmation. I am glad that the matter of combining
> C-SIDs of different flavors is clear now.
>
>
>
> Thanks,
>
> Francois
>
>
>
> *Date: *Thursday, 7 October 2021 at 20:15

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 9 Oct 2021 05:00:45 +0000

I've read the latest version of this document and found it provides practical mechanisms for SRv6 compression. It is in the right direction and the maturity has reached the bar for WG adoption.

Thus I support the adoption of this document.

Best regards,
Jie

From: spring [mailto:[email-masked]] On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 PM
To: SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Sat, 9 Oct 2021 09:27:34 +0000

Hi WG,

I have read the polling draft.
I think it provides a valid solution for SRv6 SID list compression in a simple way Compatible with SRH 8754 and SRv6 PGM 8986, and thus I support the adoption.

Thanks
Jingrong

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Ahmed MostafaSaleh ElSawaf <[email-masked]>
Date: Sat, 9 Oct 2021 18:05:24 +0000

Happy to see the adoption call was issued after a long-term discussion. As an operator, we have deployed SRv6 in our network, and we are paying attention to the topic of SRv6 compression all the time.

Thinking as an operator, we need the compression is defined based on SRv6 data plane, and CSID is. CSID defines flavors to provide efficient SRH encoding method that are fully compatible with SRv6 architecture (RFC8986), that is what we want in our network. Also, I see many vendors have implemented CSID and interop test has been made for a long time, so I support the adoption.

Thanks for the Chairs to handle this, it is indeed a very difficult work.

BR
AS

Dear WG:

Thanks!

Jim, Bruno & Joel

The information in this email may contain confidential material and it is intended solely for the addresses. Access to this  email by anyone else is unauthorized. If you are not the intended recipient, please delete the email and destroy any copies of it, any disclosure, copying, distribution is prohibited and may be considered unlawful. Contents of this email and any attachments may be altered, Statement and opinions expressed in this email are those of the sender, and do not necessarily  reflect those of Saudi Telecommunications Company (STC).

---

From: Tarek Saad <[email-masked]>
Date: Sun, 10 Oct 2021 04:06:25 +0000

Hi Francois,

Thanks for your responses. Please see inline..

From: Francois Clad (fclad) <[email-masked]>
Date: Friday, October 8, 2021 at 1:14 PM
To: Tarek Saad <[email-masked]>, James Guichard <[email-masked]>, SPRING WG <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Tarek,

[TS]: yes.

This node processes the packet according to the behavior bound to the locally instantiated SID that was matched (see Section 4.3 of RFC 8754). There is no interpretation required.
[TS]: consider the case that two locally instantiated SIDs (carried in the DA) can match – like SID1 is contained within SID2 (or vice versa). Absence anything present in the encoded SID-sequence, how can this node reliably infer whether it is G-SID sequence or a C-CSID sequence?

It is the responsibility of the SR source to make sure that the SIDs in the Segment-List are used appropriately. This applies to all SRv6 SIDs, including those defined in RFC 8986. It is the same as ensuring that there is not an End.DT4 SID in the middle of the Segment-List or that an End.X SID bound to the right interface is used.
[TS]: I’m not sure it is solely a SR source responsibility. There is some responsibility that the node allocated the 2 kinds of SIDs that need to ensure no such previous collision can ever occur, no?

Regards,
Tarek

Thanks,
Francois

Regards,
Tarek

Thanks!

Jim, Bruno & Joel

---

From: "Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ]" <[email-masked]>
Date: Sun, 10 Oct 2021 20:30:38 +0000

Dear WG,

As a multi-national operator who has deployed SRv6 in some of our markets, we believe we need the SRv6 compression mechanism based on the SRv6 data plane. After reading the CSID, Compression requirements and analysis drafts, I think CSID is the way to go for standardization in IETF, and luckily, that is happening now, so I strongly support the adoption.

I also see many vendors have implemented CSID, and some interoperability test have been made on this, so I believe the mechanism is mature enough. Hope we can have CSID adopted soonest, while the issues can be addressed in the progress following IETF process.
Thanks so far for the work done by the Chairs and DT members.

​Warm regards,
Luc-Fabrice
 
Ndifor
Specialist - IP Access and Data center
[email-masked]
T +237 677 55 02 13
Head Office: 360, Rue Drouot
​P.O. Box 15 574 Douala, Cameroon
T +237 679 00 90 90
 | mtn.cm
This email is confidential. If you have received it in error, you are on notice of its status. Please notify ​the ​​sender immediately by 
​reply email and then delete this message from your system. Please do not copy it ​or use it for any purpose or disclose its content 
​to any other person as to do so could be a breach of ​confidentiality.
​
 Please be informed that no employee or agent is authorized to conclude any legally binding agreement ​on behalf of MTN Cameroon
​via email. This can be only done if the email is confirmed explicitly in writing ​by an MTN Cameroon authorized officer. In no event 
​will this email or its content be construed as a written ​approval.
From: spring <[email-masked]> On Behalf Of James Guichard
Sent: Friday, October 1, 2021 3:05 PM
To: SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Huzhibo <[email-masked]>
Date: Mon, 11 Oct 2021 11:04:12 +0000

Hi SPRING,

>From my understanding, REPLACE-CSID flavor and NEXT-CSID flavor just like PSP, USP, USD flavor defined in RFC8986. I cannot treat PSP, USP, USD as different data planes. All the SRv6 behaviors will have different data plane behaviors, but they are built under the same data plane, SRv6. Like we have different IPv6 address type, different forwarding actions will be bound to them, but they are under the same IPv6 data plane.

>From the implementation aspect, we have implemented REPLACE-CSID in CSID for a long time, and now REPLACE-CSID flavor is available in almost all the Huawei routers, and over 10 multiple vendors interop test have been made one year ago. We also have finished the interop-test with NEXT-CSID flavor in CMCC's lab one years ago. Therefore, from the maturity of running code, I think we should adopt CSID draft.

Moreover, from the SPRING WG and the DT outputs, I can see from the rough consensus aspect, we should adopt CSID draft, so I strongly support CSID adoption.

Thanks

Zhibo

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Peter Psenak <[email-masked]>
Date: Mon, 11 Oct 2021 13:22:16 +0200

I support the adoption of the draft by the SPRING WG to continue the 
work on it.

The draft adds new flavors to the SR endpoint behaviors for the support 
of the SRv6 Segment-List compression in conformance with the RFC 8754 
and the RFC 8986.

thanks,
Peter

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 11 Oct 2021 20:48:33 +0800

Hi Chairs & WG,

I support the adoption call. Regarding chair’s note in the email, I would like to point that CSID is single SRv6 based data plane that defines next and replace behaviors consistent with the network programming paradigm.

Regards,
Peng Liu(CMCC)

[email-masked]
 
From: James Guichard
Date: 2021-10-01 22:04
To: SPRING WG

 

 
Thanks!
 
Jim, Bruno & Joel

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 11 Oct 2021 22:11:27 +0800

Hi, all

    I support the adoption. CSID is a needed solution for the SRv6 based data plane. 

Best Regards
Zongpeng Du

[email-masked] & [email-masked]
 
From: James Guichard
Date: 2021-10-01 22:04
To: SPRING WG

 

 
Thanks!
 
Jim, Bruno & Joel

---

From: Ron Bonica <[email-masked]>
Date: Tue, 12 Oct 2021 01:18:27 +0000

Jim,

Before accepting this document, we might want to discuss why the NEXT-C-SID behavior and the REPLACE-C-SID behavior are both needed. Even if there are use cases in which one performs slightly better than the other, it the performance improvement really worth all of the additional complexity?

                                                                                                                         Ron

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Rishabh Parekh <[email-masked]>
Date: Mon, 11 Oct 2021 18:31:15 -0700

With regards to the chair's question, CSID is based on the single SRv6
based data plane. The addition of flavors for SRv6 compression does not
mean the draft is defining multiple data planes. This is because, if we go
with that logic, RFC8986, which is a product of the Spring WG has already
defined many behaviors with the applicable flavors. That does not mean
RFC8986 defines multiple data planes!

I strongly support the WG adoption call.

Thanks,
Rishabh Parekh

---

From: "Kang, Haitao" <[email-masked]>
Date: Tue, 12 Oct 2021 02:07:47 +0000

I support the adoption of CSID draft.
CSID draft defines next and replace behaviors that are consistent with the SRv6 network programming RFC8996.
We've verified the solution with partners in Intel Tofino programmable switch chipset.

Regards,
Haitao

On Fri, Oct 1, 2021 at 7:05 AM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Sébastien Parisot <[email-masked]>
Date: Tue, 12 Oct 2021 11:43:38 +0200 (CEST)

Dear chairs and WG,

I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression.

A SID compression mechanism is needed and this draft specifies one that is both efficient (as the DT documented) and consistent with standardized SRv6 architecture and dataplane.

Thanks,
Sébastien

----- Mail original -----
> De: "James Guichard" <[email-masked]>
> À: "SPRING WG List" <[email-masked]>
> Envoyé: Vendredi 1 Octobre 2021 16:04:48
> Objet: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

> 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 [
> |
> ] as the basis for its compression standardization work. That is part of what
> adoption ending October 15 th for [
> |
> ] but with some clear guidelines as follows. By expressing support for adoption
>    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
>        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
> 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
> 
> 
> 
> 
>

---

From: "DiVincenzo, Mike" <[email-masked]>
Date: Mon, 11 Oct 2021 17:19:39 +0000

I would like to express my support for the Compressed SRv6 Segment List Encoding in SRH draft.  As an architect for one of the world’s largest Solutions providers, we have quite a bit of interest in this solution.  I have been involved in SR since 2013 and have been following SRv6 implementation for quite a while.  Not only is this solution elegant and straightforward, but well needed. I encourage the IETF to adopt this draft for a proposed standard.

________________________________________________

Mike DiVincenzo
Technical Solutions Architect (MPLS/SR)
World Wide Technology | Global Engineering
Office: 980.273.7901  |  Mobile: 919.741.8314
Email: [email-masked]<mailto:[email-masked]>  |  CCIE #9358

On Oct 1, 2021, at 10:05 AM, James Guichard <[email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Francesco Lombardo <[email-masked]>
Date: Tue, 12 Oct 2021 09:52:12 +0200

Hi WG,

I have been working on developing a Kubernetes network datapath solution 
using the SRv6 network programming defined in RFC8986.
I would like to thank the DT team for the hard work over the past months.
The DT analysis doc shows the CSID solution outperforms other options 
and is based on the SRv6 data plane.

CSID defines two new flavors (next and replace) in the same way as the 
flavors defined in RFC8986.

Thanks
Francesco

---

From: Marco Bonola <[email-masked]>
Date: Tue, 12 Oct 2021 11:21:11 +0200

Dear all,

I am Marco Bonola, senior researcher at CNIT (Italy), and I have 
recently worked on the SRv6 dataplane in the context of SmartNIC and 
in-Kernel acceleration. The new flavor designed in this draft compiles 
with the SRv6 dataplane and can be implemented on top of it, as other 
flavors defined in RFC8986.

Kind regards

Marco

---

From: "Carmine Scarpitta" <[email-masked]>
Date: Tue, 12 Oct 2021 11:37:59 +0200

Hi WG, 

I have spent a lot of time doing performance measurements for SRv6 dataplane implementations in open-source stack including Linux Kernel, VPP and others. 

The measurements included SRv6 behaviors defined in RFC8986 as well as the flavors defined for End, End.X and End.T behaviors. 

The flavors defined in the CSID draft are complaint with RFC8986 and builds on top of the single SRv6 dataplane. 

Thanks 

Carmine

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Mike Koldychev (mkoldych)" <[email-masked]>
Date: Tue, 12 Oct 2021 15:54:28 +0000

Hi WG,

The draft is based on SRv6 data plane with flavors defined for SRv6 compression, as per RFC8986. It is coherent with the one data plane solution objective.
I strongly support the adoption of the draft.

Thanks,
Mike.

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Oct 2021 03:33:18 +1100

Dear Chairs,

I object to the WG adopting this draft.

If SIDs are IPv6 addresses, then this draft is fundamentally relying
on encoding a segment list of SIDs (with a common high order prefix),
and therefore a list of multiple IPv6 addresses, in the IPv6
Destination Address field.

Clearly the IPv6 DA field is to only carry a single IPv6 address - it
would be called the IPv6 Destination Addresses or perhaps IPv6
Destination Address List field if it were to contain a list of IPv6
addresses (SIDs).

As far as I can see, it would not be possible to remove this
multiple-SID/address encoding in the single IPv6 DA address field from
this draft without invalidating the entire draft. Adoption by the WG
will not fix that.

Being able to implement it does not make it a good idea. It just shows
it is not impossible to implement.

There are other ways SIDs could be compressed that also comply with
the IPv6 RFCs - firstly by starting having a much smaller yet quite
adequate SID size, such as 32 bits, or the 20 bit size used with
SR-MPLS, and then encoding the single smaller SID value in an IPv6
address, when the SID is placed into an IPv6 DA field, such as how 32
bit IPv4 addresses are encoded in IPv6 addresses, per RFC4291, 2.5.5.
IPv6 Addresses with Embedded IPv4 Addresses.

Regards,
Mark.

---

From: David Lo Bascio <[email-masked]>
Date: Tue, 12 Oct 2021 20:32:24 +0200

I support the WG adoption of draft-filsfilscheng-spring-srv6-srh-compression.
My research activity is related on leveraging SRv6 to implement a containerized SFC on Kubernetes.
The new flavors added to the SR endpoint behaviors will be useful to this scope, simplifying the processing on each cluster node.
It is quite clear to me they belong to a singe SRv6 data plane.

--
David Lo Bascio
PhD Student in ICT
Department of Information Engineering,
Electronics and Telecommunications (DIET)
Sapienza University of Rome
+39 331 63 51 362
[email-masked]

---

From: Primadi Hendra Kusuma <[email-masked]>
Date: Tue, 12 Oct 2021 21:31:29 +0000

Dear WG,

The draft, as far as I can understand, defines REPLACE-CSID and NEXT-CSID flavours in order to enable efficient SRH encoding capability, and it is based on a single SRv6 data plane. I highly endorse the adoption of CSID as an operator who is going to deploy multi-vendors SRv6 in the near future. We're wishing to standardize the CSID so that we can adopt a uniform solution across the network.

Regards,

Sent: Friday, October 1, 2021 9:05 PM

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Oct 2021 01:43:19 +0000

Hi,

I have read the draft and been following this discussion of SRH compression. Since the WG has agreed to address the SRH compression issue, the draft proposes a reasonable way to do that, and the quality of the document is above the average, IMHO.

Therefore, I support the adoption of the document,  and then the draft can be improved, modified and progressed according to the WG consensus.

Best regards,
Mach

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 13 Oct 2021 11:03:38 +0900

Dear SPRING WG,

I support this adoption for draft-filsfilscheng-spring-srv6-srh-compression.

After I read the draft with the related DT documents, I understand that NEXT and REPLACE flavors comply with RFC8986, and satisfied all the requirements at high level. I really appreciate all DT members efforts that brings this draft to the WG. 

Best regards,
--satoru

> On Oct 1, 2021, at 23:05, James Guichard <[email-masked]> wrote:
> 
> 
> Dear WG:
>

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Wed, 13 Oct 2021 02:47:26 +0000

Hi WG,

We are working on SRv6 for many years, and a lots of innovations are built on SRv6. CSID uses the existing SRv6 data plane and control plane extensions to provide efficient encoding of SRH so that we can mitigate a lot of complexities and workload of implementation and standardization. Therefore, I support the adoption.

Regards,
Haibo

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 13 Oct 2021 09:40:19 +0530

Hi Chairs,

I would not consider new flavors to the existing endpoint behaviors as
multiple data planes. At least that's not what I thought of when responding
to the earlier poll. Either way, this I-D is a good base for making
progress. In fact, making sure that the I-D is in WG control is a much
better way to further the discussion. Thus, I support adoption. Thanks to
Joel for posting the summary in 6man as well.

Some suggestions to authors:

- Some sections could use some more explanation and text instead of the
reader guessing why. For example section 6.3
- There is a lot of lower case "recommended" in this I-D. Perhaps, some of
these might be more suitable as RECOMMENDED.

Section 2

   o  Compressed-SID (C-SID): A C-SID is a short encoding of a SID in
      SRv6 packet that does not include the SID block bits (locator
      block).

What about the argument? In other places, we say NF is C-SID length (which
does not include argument) and thus I am not sure.

Section 3

   These common bits are named Locator-Block in [RFC8986]

I did not find the term "Locator-Block" in RFC 8986. They do use the term
SRv6 SID block though.

Section 10

   Illustrations will be provided in a separate document.

An example/illustration is needed to visualize and understand this
document. I urge authors to consider adding it as part of this document
itself, perhaps as an appendix.

Nits
- Expand SRv6, SID, PCE on first use.

Thanks!
Dhruv

---

From: <[email-masked]>
Date: Wed, 13 Oct 2021 05:30:38 +0000

Dear WG,

I support the adoption of draft https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-filsfilscheng-spring-srv6-srh-compression%2F&data=04%7C01%7CThomas.Graf%40swisscom.com%7C3792124391de422b6fa708d98c87ba03%7C364e5b87c1c7420d9beec35d19b557a1%7C0%7C0%7C637695336840814510%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dKeXd8%2FsV696TUgip57usUroIXQllJTApl%2FRABCpEB8%3D&reserved=0> and use it as the basis for its compression standardization work.

I found the document draft-ietf-spring-compression-requirement and draft-ietf-spring-compression-analysis very useful to understand the context.

Best wishes
Thomas

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Pier Luigi Ventre <[email-masked]>
Date: Tue, 12 Oct 2021 18:21:15 +0200

Dear J. Guichard, Spring WG and Spring Chairs
we support the adoption of draft-filsfilscheng-spring-srv6-srh-compression. To the best of our knowledge, CSID is single SRv6 based data plane that defines next and replace flavors to End, End.X, and End.T SIDs and it is consistent with RFC8996

Best regards
Pier Luigi Ventre (UniRoma2)

> On Oct 1, 2021, at 4:04 PM, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>

---

From: Paolo Lungaroni <[email-masked]>
Date: Tue, 12 Oct 2021 18:43:37 +0200

I have been working together with my team at the university of Rome Tor Vergata on SRv6 support in the Linux kernel. 

The CSID draft builds on RFC8986 and defines two new flavors. 
We supported these two flavors in the Linux kernel by re-using the same infrastructure developed to support the flavors defined in RFC8986. 

Which confirms that the new flavors build on the single dataplane (SRv6 dataplane).

Thanks 
Paolo

> Il giorno 01 ott 2021, alle ore 16:04, James Guichard <[email-masked]> ha scritto:
> 
> Dear WG:
>  
> 	• 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.".
>

---

From: Andrea Mayer <[email-masked]>
Date: Tue, 12 Oct 2021 18:49:28 +0200

Dear WG, WG chairs,

I support the adoption of CSID draft (draft-filsfilscheng-spring-srv6-srh-compression).

Over the past years, I have been working extensively on the SRv6 stack in the Linux kernel.
I have contributed to the Linux kernel by introducing new SRv6 features as well as optimizing current SRv6 code in the Linux.

RFC8986 defines multiple flavors for End, End.X, and End.T SID behaviors. I already developed the infrastructure to support the flavors defined in RFC8986 in the Linux kernel. CSID draft builds on RFC8986 and defines two new flavors for these SIDs. 

I have implemented CSID in the Linux kernel. The implementation leverages the same infrastructure developed for the flavors defined in RFC8986.

Thanks
Andrea

On Fri, 1 Oct 2021 14:04:48 +0000

-- 
Andrea Mayer <[email-masked]>

---

From: "Sudarshan, Reshma" <[email-masked]>
Date: Wed, 13 Oct 2021 05:52:46 +0000

Hello Spring WG,

>From Intel, we are currently in the process of adding SRv6 feature in the open source NOS - SONiC.
In our discussions with our customers about SRv6 H.encaps.red, END.X, END.DT46 etc functions that we are implementing in SONiC, we also hear about the importance of NEXT and REPLACE flavors in their deployments. For that reason we have implemented  CSID in our platform as well as added NEXT in SAI, and will continue to implement this in SONiC in the future releases. Looking at the deployment benefits, I do support the WG adoption of this draft.

Best Regards,

Reshma Sudarshan

Director of Applications Engineering, ENA | CG | NEX
Intel Corporation

Sent: Friday, October 1, 2021 7:05 AM

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Julian Klaiber <[email-masked]>
Date: Wed, 13 Oct 2021 07:56:24 +0000

Dear WG

I want to express support for the WG adoption of the draft https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ (CSID).

In my research studies at the University of Applied Sciences, I have developed a Segment Routing application capable of doing service chaining. The application uses the SRv6 encapsulation with the NEXT-C-SID flavor.

The analysis of the DT shows that CSID is performing better than the other options. Another crucial point is that CSID is based on the SRv6 data plane, and CSID also enables different deployment use-cases by adding next and replace flavors for these SIDs, like PSP, USP, and USD flavors defined in the RFC8986.

I also want to thank the DT team for their hard work over the last months.

Best Regards,

Julian

Sent: Friday, 1 October 2021 16:04

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Severin Dellsperger <[email-masked]>
Date: Wed, 13 Oct 2021 07:59:57 +0000

Dear WG

I strongly support the WG adoption for the Compressed SRv6 Segment List Encoding in SRH draft (https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/).

In different projects, I have worked with SRv6 and used the NEXT-C-SID flavor to enable Segment Routing Traffic Engineering applications, especially in the Service Programming field.

The following points convinced me for my decision:

  *   First, the CSID draft supports the different flavors defined in RFC8986 with its next and replace methods.
  *   CSID only supports SRv6 based data plane, which is IMHO the right step for the future

Kind Regards,

Severin

Sent: Friday, October 1, 2021 4:04 PM

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Kentaro Ebisawa <[email-masked]>
Date: Wed, 13 Oct 2021 18:36:48 +0900

Dear SPRING Working Group,

The SID compression mechanism described in the document will help adopting SRv6 more efficiently when having multiple SIDs with small payload, in a way consistent with a single and already standardized SRv6 dataplane.

I think the draft is already in a good state as a starting point. And I hope we can start the discussion soon to make improvements as a WG document.

Best Regards,

-- 
Kentaro Ebisawa | Mailing List:<[email-masked]>  | Work:<[email-masked]>

On 2021/10/01 23:04, James Guichard wrote:
> Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15^th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ <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:
>

---

From: "fuyuexia" <[email-masked]>
Date: Wed, 13 Oct 2021 17:56:26 +0800

Dear WG,

I support the adoption call. CSID draft defines multiple SRv6 flavors, but
they present a single SRv6 data plane based solution. 

Regards,

Yuexia Fu

发件人: spring [mailto:[email-masked]] 代表 Severin Dellsperger
发送时间: 2021年10月13日 16:00
收件人: James Guichard; SPRING WG
抄送: [email-masked]
主题: Re: [spring] WG Adoption call for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres
sion/

Dear WG

I strongly support the WG adoption for the Compressed SRv6 Segment List
Encoding in SRH draft (
<https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre
ssion/>
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres
sion/).

In different projects, I have worked with SRv6 and used the NEXT-C-SID
flavor to enable Segment Routing Traffic Engineering applications,
especially in the Service Programming field.

*	First, the CSID draft supports the different flavors defined in
RFC8986 with its next and replace methods.
*	CSID only supports SRv6 based data plane, which is IMHO the right
step for the future

Kind Regards,

Severin

  _____  

From: spring <[email-masked]> on behalf of James Guichard <james.n.
[email-masked]>
Sent: Friday, October 1, 2021 4:04 PM
To: SPRING WG <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [spring] WG Adoption call for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres
sion/ 

Dear WG:

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-compres
sion/ 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

---

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

Hi Tarek,

Section 4.3 of RFC 8754 indicates that a locally instantiated SID is identified based on the result of an LPM lookup on the packet’s destination address. That SID has a behavior that determines how the endpoint node should process the packet.

The C-SID draft does not change how the endpoint node identifies a SID.

Could you provide an example showing the kind of inference or collision you are referring to?

Thanks,
Francois

From: Tarek Saad <[email-masked]>
Date: Sunday, 10 October 2021 at 06:06
To: Francois Clad (fclad) <[email-masked]>, James Guichard <[email-masked]>, SPRING WG <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Francois,

Regards,
Tarek

Thanks,
Francois

Regards,
Tarek

Thanks!

Jim, Bruno & Joel

---

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

Hi Greg,

Your understanding is correct. The C-SID flavors cannot be randomly mixed within the same C-SID container.

We can clarify the details related to the combination of flavors in a C-SID container in an upcoming version of the draft. For example, the last entry of a C-SID container can carry a C-SID bound to any behavior, including one with another C-SID flavor.

Thanks,
Francois

From: Greg Mirsky <[email-masked]>
Date: Friday, 8 October 2021 at 22:21
To: Francois Clad (fclad) <[email-masked]>
Cc: Robert Raszuk <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, James Guichard <[email-masked]>, SPRING WG <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Francois,
you've said that different flavors of C-SID can be present not only in the same SRH but also in the same C-SID container. The latter case got me thinking about several potential scenarios. Have to admit that I got stuck trying to understand how they can work. I hope you can help me out. Please consider the two cases described below.

Consider, for all cases, that we are handling a container with entries A, B, C, and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors.

Case 1:
Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID flavor. When A is processed, B will be copied into the IPv6 DA, retaining the prefix before A in the container. So far, so good. Then, when the packet arrives at the node that processes B, it will say "NEXT". The remaining bits will be? I thought zero, but actually, it will presumably be two bits with the value two? So the subsequent behavior will shift that two up? Even if the NEXT-C-SID flavor guesses that the two should be zero, it would skip C and D and pick up the entry from the next C-SID container in the SRH. So it seems to either work wrong or work oddly?

Case 2:
Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D upwards in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will interpret the upper bits of the C C-SID as the arg for selecting the position in the C-SID container to pull an entry from. It will also modify the C C-SID to perform the decrement it thinks it needs. It will then overwrite itself with the randomly chosen entry from the container.

It seems that neither scenario works. At least, I cannot figure out how it can work. I would greatly appreciate it if you could have a look and clarify it for me.
Regards,
Greg

On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Greg,

Thanks,
Francois

Regards,
Greg

Thanks,
Francois

Regards,
Greg

Francois

Regards,
Greg

Abstract

4.1.  NEXT-C-SID Flavor

6.1.  C-SID Length

Kind regards,
Robert

                                                                                 Ron

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Wed, 13 Oct 2021 20:04:06 +0800

Dear Chairs and WG,

As a co-author of this document, I would like to thank all participants in
the discussion. All those discussions, comments and suggestions are of great
value to us.

It was unexpected that so many IETFers could join the discussion. It is
amazing. It also made me realize that the draft is very valuable.

Here I would like to raise one suggestion:

Due to National Day holiday (October 1st to October 7th) in China, many
experts interested in the draft were not fully involved in the discussion. 

Could the Working Group consider extending the adoption call by one week
more so that all members could participate fully in the discussions?

B.R.

Weiqiang Cheng

发件人: spring [mailto:[email-masked]] 代表 James Guichard
发送时间: 2021年10月1日 22:05
收件人: SPRING WG
抄送: [email-masked]
主题: [spring] WG Adoption call for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres
sion/

Dear WG:

 

Thanks!

Jim, Bruno & Joel

---

From: David Melman <[email-masked]>
Date: Wed, 13 Oct 2021 12:19:00 +0000

Marvell silicon supports the SRv6 CSID flavors REPLACE-CSID and NEXT-CSID, and Marvell has participated in multi-vendor interoperability testing of these CSID flavors.

David

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

External Email

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfilsfilscheng-2Dspring-2Dsrv6-2Dsrh-2Dcompression_&d=DwMFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=QmgeAx3FBTO5s5SiLkMF0kKr2hmFESV-Jif0H28xnCs&m=QyeZ7IN8W75uqLz5o-Ns01fXF6rFrEqm1-jvPcEWfX8&s=vTbmENGQL8KGlVuCpApLRywxBS56YlWlciQgqUdTu60&e=> 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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfilsfilscheng-2Dspring-2Dsrv6-2Dsrh-2Dcompression_&d=DwMFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=QmgeAx3FBTO5s5SiLkMF0kKr2hmFESV-Jif0H28xnCs&m=QyeZ7IN8W75uqLz5o-Ns01fXF6rFrEqm1-jvPcEWfX8&s=vTbmENGQL8KGlVuCpApLRywxBS56YlWlciQgqUdTu60&e=> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Oct 2021 20:54:24 +0800

Hi Dear WG, 
    We have deployed SRv6 in our national-wide large scale networks for a long time to provide better Internet services for over 1 billion people. Furthermore, almost one year ago, we had decided to use the mechanism defined in this draft in our network in the near future. 
 I support the adoption of this draft. Thanks.B.R.Yongqing Zhu

[email-masked]
 
From: James Guichard
Date: 2021-10-01 22:04
To: SPRING WG

 

 
Thanks!
 
Jim, Bruno & Joel

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 13 Oct 2021 10:07:43 -0400

I will consider this as we reach the current closure date.
Yours,
Joel

On 10/13/2021 8:04 AM, Weiqiang Cheng wrote:
> Dear Chairs and WG,
> 
> As a co-author of this document, I would like to thank all participants 
> in the discussion. All those discussions, comments and suggestions are 
> of great value to us.
> 
> *发件人:*spring [mailto:[email-masked]] *代表 *James Guichard
> *发送时间:*2021年10月1日22:05
> *收件人:*SPRING WG
> *抄送:[email-masked]
> *主题:*[spring] WG Adoption call for

---

From: Paul Mattes <[email-masked]>
Date: Wed, 13 Oct 2021 20:05:22 +0000

I support adoption. The document describes changes that are consistent with existing SRv6-related RFCs, and I find the objection about multiple apparent data plane solutions to be puzzling at best.

                pdm

Sent: Friday, October 1, 2021 9:05 AM

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Xing James Jiang (jamjiang)" <[email-masked]>
Date: Thu, 14 Oct 2021 05:09:23 +0000

Hi Chairs & WG,

I fully support the adoption of the draft.

From October to December 2020, I led the CSID multi-vendor interoperability test in the China Mobile Lab. The joint team successfully verified that different vendors implement data plane interoperability based on the CSID draft. We tested end-to-end NEXT Flavor, end-to-end REPLACE Flavor and Hybrid NEXT + REPLACE flavor use cases. The three application scenarios of CSID Flavor proved that the CSID draft can achieve header compression on existing network equipment and the interoperability of two different Flavors on a single data plane.

I hope this interoperability test will help the working group to adopt the CSID draft.

Thanks & Regards

Xing James Jiang

发件人: spring <[email-masked]> 代表 James Guichard
发送时间: 2021年10月1日 22:05
收件人: SPRING WG <[email-masked]>
抄送: [email-masked]
主题: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Tetsuya Murakami <[email-masked]>
Date: Wed, 13 Oct 2021 22:45:19 -0700

Dear WG,

Based on my understanding, NEXT and REPLACE flavors defined in this draft can meet with RFC8986. Also, there are multiple implementations today like Arrcus and VPP as well. I really appreciate the huge efforts made by DT team in order to deliver this draft.

Thanks,
Tetsuya

> On Oct 1, 2021, at 7:04 AM, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>

---

From: Takuya Miyasaka <[email-masked]>
Date: Thu, 14 Oct 2021 16:55:48 +0900

Hi,

While SRv6 has high potential, for a simple operation such as TE the 
high packet length overhead of SRv6 has been an issue for operators. 
This draft resolves this issue and  (I believe) a necessary feature for 
operators, so we would like to support this draft.

Thanks,
Takuya

---

From: andre beliveau <[email-masked]>
Date: Thu, 14 Oct 2021 14:49:26 -0400

Dear WG and the WG Chairs,

The draft
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dfilsfilscheng-2Dspring-2Dsrv6-2Dsrh-2Dcompression_&d=DwMFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=QmgeAx3FBTO5s5SiLkMF0kKr2hmFESV-Jif0H28xnCs&m=QyeZ7IN8W75uqLz5o-Ns01fXF6rFrEqm1-jvPcEWfX8&s=vTbmENGQL8KGlVuCpApLRywxBS56YlWlciQgqUdTu60&e=>
  is based on SRv6 data plane (RFC8986).  RFC8996 already defines multiple
behaviors and flavors.  As such, RFC8986 nor this draft mandates an SRv6
data plane node to support all behaviors and flavors.  It only  adds additional
flavors for SRv6 compression to RFC8986.

We, at NoviFlow, have implemented a CSID solution.

I strongly support the adoption of the draft and believe that it is valid
and coherent with the WG objective of one data plane solution.

Regards,
André Béliveau
NoviFlow

-- 

*André Béliveau*

Director Product Management

M : +1 514-502-9592

[email-masked]

www.noviflow.com

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 15 Oct 2021 00:41:22 +0000

I oppose for the same reasons as well.

From: spring <[email-masked]> On Behalf Of Tarek Saad
Sent: Friday, October 8, 2021 12:05 AM
To: James Guichard <[email-masked]>; SPRING WG <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Hi all,

I've read this draft. It is proposing 2 different encodings schemes for compressed sequence of SRv6 SIDs (and an optional behavior on border nodes)..
Although Section 4 makes a claim that different deployments usecase may deem one encoding scheme superior over the other, I could not glean in which cases a scheme would outperform the other and why? Or, why is the WG trying to standardize both the two flavors -- keeping in mind the complex HW procedures evident by the proposed different pseudo codes in the draft.

Regards,
Tarek

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!SwItTYRfm5AFHnLo8ht4Ubvk8uLGbSvFmvSyrCdXOoZGmG7cbtKin0BgXloxePaE$> 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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/__;!!NEt6yMaO-gk!SwItTYRfm5AFHnLo8ht4Ubvk8uLGbSvFmvSyrCdXOoZGmG7cbtKin0BgXloxePaE$> but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

Thanks!

Jim, Bruno & Joel

---

From: "Luis M. Contreras" <[email-masked]>
Date: Fri, 15 Oct 2021 15:12:10 +0200

Hi all,

I support the adoption of this draft which goes in line with the
conclusions of the DT analysis, as the basis for a compression solution
defined by the WG.

I'm planning to perform interop tests in the forthcoming months, so further
operational feedback can be provided afterwards.

Best regards

Luis

> addressed should the document be adopted into the working group.

_________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica

---

From: 田辉 <[email-masked]>
Date: Thu, 21 Oct 2021 16:49:03 +0800

Hi  ALL，
 
After a long-term discussion in the WG, we have reached this point today
I support the adoption of CSID draft, which describes an efficient solution of SRv6 compression.
I understand the document defines several Flavors, and I think it is just like the normal flavors defined in RFC8986, like PSP, USP, so it makes sense to me.
Again, thanks to chairs and design team.
 
Best regards,
TIAN

> On Oct 1, 2021, at 22:04, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>

---

From: TIAN <[email-masked]>
Date: Thu, 21 Oct 2021 16:51:02 +0800

Hi  ALL，

Best regards,
TIAN

田辉

中国信息通信研究院
010-62300052 [email-masked]
北京市海淀区花园北路52号3G楼B座

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

---

From: 庞冉(联通集团中国联通研究院-本部) <[email-masked]>
Date: Fri, 22 Oct 2021 02:35:58 +0000

Hi，WG，

I am sorry it seems too late to respond to the adoption call. I would like to express my support for the draft.
As an operator, We do need a SRH header compression standard. Hence, we’re looking forward to any progress in it.

Best regards,
Pang Ran.

From: James Guichard<mailto:[email-masked]>
Date: 2021-10-01 22:04
To: SPRING WG<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Dear WG:

Thanks!

Jim, Bruno & Joel

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: John Scudder <[email-masked]>
Date: Tue, 26 Oct 2021 17:58:33 +0000

(For clarity: I’m wearing no hats other than “WG contributor”.)

As noted in https://mailarchive.ietf.org/arch/msg/spring/5HF4wM5ZDcw5DeL_klXmKf1UP0E/, I’m opposed to adoption until the issue raised there has been addressed. (Repeating the point here to aid in issue tracking.)

Regards,

—John

> On Oct 1, 2021, at 10:04 AM, James Guichard <[email-masked]> wrote:
> 
> 
> Dear WG:
>  
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!XRZdfRhOii89II8Mv7l5YKxFHZqsAZ-AstsTtWa3rzgzsl3lqS-NbXMcEh_4oA$

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 26 Oct 2021 14:28:20 -0700

Dear Francois et al.,
I appreciate your consideration of the scenarios when both compression
methods were used. I'll be looking for the next update of the draft. I hope
the authors will add a section with a clear description of scenarios when
the two compression methods can be used.
But in the meantime, I am still strongly concerned that adoption of the
draft in its current version would violate the decision of the WG (as I
understand the result of the earlier poll) to adopt a single compression
method (not a single document that defines two (at the minimum)
incompatible methods to compress SRv6 SIDs. I've read multiple notes that
asserted that in the testing, the ability to mix REPLACE-C-SID and
NEXT-C-SID was verified and confirmed. It seems to me that sharing more
information about these tests could address my concern.

But at this time, I strongly object to SPRING WG's adoption of the current
draft version as it would violate the earlier decision reached by the WG.

Regards,
Greg

On Wed, Oct 13, 2021 at 3:56 AM Francois Clad (fclad) <[email-masked]>
wrote:

> We can clarify the details related to the combination of flavors in a
> C-SID container in an upcoming version of the draft. For example, the last
> entry of a C-SID container can carry a C-SID bound to any behavior,
> including one with another C-SID flavor.
>
>
>
> Thanks,
>
> Francois
>
>
>
> *Date: *Friday, 8 October 2021 at 22:21