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

[Greg Mirsky]

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) 
wrote:

> 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 
> *Date: *Friday, 8 October 2021 at 22:21
> *To: *Francois Clad (fclad) 
> *Cc: *Robert Raszuk , Ron Bonica  40juniper@dmarc.ietf.org>, James Guichard <
> james.n.guich...@futurewei.com>, SPRING WG ,
> spring-cha...@ietf.org 
> *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) 
> 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
>
>
>
> *From: *Greg Mirsky 
> *Date: *Thursday, 7 October 2021 at 20:15
> *To: *Francois Clad (fclad) 
> *Cc: *Robert Raszuk , Ron Bonica  40juniper@dmarc.ietf.org>, James Guichard <
> james.n.guich...@futurewei.com>, SPRING WG ,
> spring-cha...@ietf.org 
> *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
> relat

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

[John Scudder]

(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  
> 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.
>  
> The apparent inclination of the working group is to use 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
>  
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that:
>  
>   • The SPRING working group is adopting a document that has multiple 
> SRv6 Endpoint behaviors.
>   • The document is a “living” document; it may change as it goes through 
> review and analysis by the SPRING working group.
>   • All open discussion points raised on our mailing list MUST be 
> addressed BEFORE said document is allowed to progress from the working group 
> to publication. A list of these discussion points will be documented in the 
> WG document and maintained by the document editor in conjunction with the 
> chairs.
>   • If this document is adopted by the working group, the chairs specify 
> as part of the adoption call that the following text describing an open issue 
> be added to the document in the above-described open issues section:
>   • "Given that the working group has said that it wants to 
> standardize one data plane solution, and given that the document contains 
> multiple SRv6 EndPoint behaviors that some WG members have stated are 
> multiple data plane solutions, the working group will address whether this is 
> valid and coherent with its one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!XRZdfRhOii89II8Mv7l5YKxFHZqsAZ-AstsTtWa3rzgzsl3lqS-NbXMcEh_4oA$

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[联通集团中国联通研究院-本部]

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
Date: 2021-10-01 22:04
To: SPRING WG
CC: spring-cha...@ietf.org
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/
 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


如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 
hqs-s...@chinaunicom.cn，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received 
this email in error please notify us immediately by e-mail. Please reply to 
hqs-s...@chinaunicom.cn ,you can unsubscribe from this mail. We will 
immediately remove your information from send catalogue of our.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[TIAN]

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




田辉

中国信息通信研究院
010-62300052 tian...@caict.ac.cn
北京市海淀区花园北路52号3G楼B座

> On Oct 1, 2021, at 22:04, 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.
>  
> The apparent inclination of the working group is to use 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  
> 
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
>  
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  
> but
>  with some clear guidelines as follows. By expressing support for adoption of 
> this document you are fully aware of and are acknowledging that:
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors.
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group.
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the chairs.
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org 
> https://www.ietf.org/mailman/listinfo/spring 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[田辉]

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  
> 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.
>  
> The apparent inclination of the working group is to use 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  
> 
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
>  
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  
> 
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that:
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors.
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group.
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the chairs.
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org 
> https://www.ietf.org/mailman/listinfo/spring 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Giuseppe Siracusano]

Dear WG, WG Chairs,

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

I have been working on SRv6 for different research project over the last
years.
The flavors defined in the CSID draft are complaint with RFC8986 and builds
on top of the single SRv6 dataplane.

Thanks
Giuseppe Siracusano, PhD


Dear WG:



The chairs would like to express their appreciation for all the responses
received to our emails with reference to how the working group wishes to
move forward with respect to a solution for SRv6 compression.



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



Because of the above the chairs would like to issue a 2-week WG call for
adoption ending October 15th for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
but with some clear guidelines as follows. By expressing support for
adoption of this document you are fully aware of and are acknowledging
that:



   1. The SPRING working group is adopting a document that has multiple
   SRv6 Endpoint behaviors.
   2. The document is a “living” document; it may change as it goes through
   review and analysis by the SPRING working group.
   3. All open discussion points raised on our mailing list MUST be
   addressed BEFORE said document is allowed to progress from the working
   group to publication. A list of these discussion points will be documented
   in the WG document and maintained by the document editor in conjunction
   with the chairs.
   4. If this document is adopted by the working group, the chairs specify
   as part of the adoption call that the following text describing an open
   issue be added to the document in the above-described open issues section:
  - "Given that the working group has said that it wants to standardize
  one data plane solution, and given that the document contains
multiple SRv6
  EndPoint behaviors that some WG members have stated are multiple
data plane
  solutions, the working group will address whether this is valid and
  coherent with its one data plane solution objective.".



Please consider the above guidelines as you decide on whether to support or
not this WG adoption. Please express clearly your reasoning for
support/non-support as well as any open discussion points you would like
addressed should the document be adopted into the working group.



Thanks!



Jim, Bruno & Joel
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Luis M. Contreras]

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


El vie, 1 oct 2021 a las 16:05, James Guichard (<
james.n.guich...@futurewei.com>) escribió:

> Dear WG:
>
>
>
> The chairs would like to express their appreciation for all the responses
> received to our emails with reference to how the working group wishes to
> move forward with respect to a solution for SRv6 compression.
>
>
>
> The apparent inclination of the working group is to use
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> as the basis for its compression standardization work. That is part of what
> this email attempts to confirm.
>
>
>
> Because of the above the chairs would like to issue a 2-week WG call for
> adoption ending October 15th for
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> but with some clear guidelines as follows. By expressing support for
> adoption of this document you are fully aware of and are acknowledging
> that:
>
>
>
>1. The SPRING working group is adopting a document that has multiple
>SRv6 Endpoint behaviors.
>2. The document is a “living” document; it may change as it goes
>through review and analysis by the SPRING working group.
>3. All open discussion points raised on our mailing list MUST be
>addressed BEFORE said document is allowed to progress from the working
>group to publication. A list of these discussion points will be documented
>in the WG document and maintained by the document editor in conjunction
>with the chairs.
>4. If this document is adopted by the working group, the chairs
>specify as part of the adoption call that the following text describing an
>open issue be added to the document in the above-described open issues
>section:
>   - "Given that the working group has said that it wants to
>   standardize one data plane solution, and given that the document 
> contains
>   multiple SRv6 EndPoint behaviors that some WG members have stated are
>   multiple data plane solutions, the working group will address whether 
> this
>   is valid and coherent with its one data plane solution objective.".
>
>
>
> Please consider the above guidelines as you decide on whether to support
> or not this WG adoption. Please express clearly your reasoning for
> support/non-support as well as any open discussion points you would like
> addressed should the document be adopted into the working group.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>


_
Luis M. Contreras
contreras.i...@gmail.com
luismiguel.contrerasmuri...@telefonica.com
Global CTIO unit / Telefonica
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Bao,Guixin]

Hi, Dear WG

I support the adoption of this draft.

From the user point of view, I think the CSID proposes a highly efficient way  
for SRv6 compression, and it can make the network programming model (RFC8986) 
be easier to deploy. CSID is just adding the next and replace flavors and still 
maintain a single SRv6 based data plane.

Thanks.

Guixin Bao
Baidu  Network Chief Architect

发件人: spring  代表 James Guichard 

日期: 2021年10月1日 星期五 22:04
收件人: SPRING WG 
抄送: "spring-cha...@ietf.org" 
主题: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Kalyani Rajaraman]

Dear WG,

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

We, at Arrcus have implemented CSID solution on the following hardware
Products:

  Arrcus Quanta (IXAE, IXA) Broadcom Jericho-2 based platforms.
  Arrcus Edgecore (AS7962) Jericho-2 based platforms.

Thanks,
Kalyani


On Thu, Oct 14, 2021 at 3:49 AM Shay Zadok  wrote:

> Dear WG,
>
> We would like to update on the production support by the StrataDNX
> products of both flavors REPLACE and NEXT as defined in CSID draft, as well
> as non-compressed "Classic" SRv6.
> StrataDNX products include:
> Jericho2/Jericho2c/Qumran2c/Qumran2a/Qumran2u/Qumran2n/Jericho2c+ and any
> future device
>
> This support keeps:
> 1. Single and unified data-plane uCode, programmed using high level
> language
> 2. Single data-plane API
> 3. Concurrent/Simultaneous support of all three techniques based on a
> per-packet behavior
> 4. Concurrent/Simultaneous support of all three techniques inside of the
> same SRv6 Header
> 5. In all three techniques the following is already supported 
> concurrently/simultaneously
> and in production
> 1. SRv6 main behaviors - compliant with *rfc8986*
> 2. SRv6 insert behaviors - compliant with
> *draft-srv6-net-pgm-insertion*
> 3. SRv6 midpoint protection behaviors - compliant with
> *draft-midpoint-protection*
>
> All of the above is in production deployment in various published and
> unpublished networks around the globe.
> Our products are used by industry leading OEM (some of them published they
> are using the StrataDNX products) and "pure" NOS vendors.
>
> BRCM using Jericho2 participated in couple of interops that included some
> mix of REPLACE-CSID, NEXT-CSID and non-compressed "Classic" SRv6 - and all
> interops have ended successfully
>
> Thanks & Regards,
> Shay
>
>
>
>
>
>
> *发件人:* spring [mailto:spring-boun...@ietf.org] *代表 *James Guichard
> *发送时间:* 2021年10月1日 22:05
> *收件人:* SPRING WG 
> *抄送:* spring-cha...@ietf.org
> *主题:* [spring] WG Adoption call for
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>
>
>
> Dear WG:
>
>
>
> The chairs would like to express their appreciation for all the responses
> received to our emails with reference to how the working group wishes to
> move forward with respect to a solution for SRv6 compression.
>
>
>
> The apparent inclination of the working group is to use
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  as
> the basis for its compression standardization work. That is part of what
> this email attempts to confirm.
>
>
>
> Because of the above the chairs would like to issue a 2-week WG call for
> adoption ending October 15th for
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  but
> with some clear guidelines as follows. By expressing support for adoption
> of this document you are fully aware of and are acknowledging that:
>
>
>
>1. The SPRING working group is adopting a document that has multiple
>SRv6 Endpoint behaviors.
>2. The document is a “living” document; it may change as it goes
>through review and analysis by the SPRING working group.
>3. All open discussion points raised on our mailing list MUST be
>addressed BEFORE said document is allowed to progress from the working
>group to publication. A list of these discussion points will be documented
>in the WG document and maintained by the document editor in conjunction
>with the chairs.
>4. If this document is adopted by the working group, the chairs
>specify as part of the adoption call that the following text describing an
>open issue be added to the document in the above-described open issues
>section:
>
>
>- "Given that the working group has said that it wants to standardize
>   one data plane solution, and given that the document contains multiple 
> SRv6
>   EndPoint behaviors that some WG members have stated are multiple data 
> plane
>   solutions, the working group will address whether this is valid and
>   coherent with its one data plane solution objective.".
>
>
>
> Please consider the above guidelines as you decide on whether to support
> or not this WG adoption. Please express clearly your reasoning for
> support/non-support as well as any open discussion points you would like
> addressed should the document be adopted into the working group.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
>
>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are 

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

[Jeffrey (Zhaohui) Zhang]

I oppose for the same reasons as well.

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

[External Email. Be cautious of content]

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


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of James Guichard 
mailto:james.n.guich...@futurewei.com>>
Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>
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://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:


  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




Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[andre beliveau]

Dear WG and the WG Chairs,

The draft
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

  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


On Fri, Oct 1, 2021 at 10:05 AM James Guichard <
james.n.guich...@futurewei.com> 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.
>
>
>
> The apparent inclination of the working group is to use
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> as the basis for its compression standardization work. That is part of what
> this email attempts to confirm.
>
>
>
> Because of the above the chairs would like to issue a 2-week WG call for
> adoption ending October 15th for
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> but with some clear guidelines as follows. By expressing support for
> adoption of this document you are fully aware of and are acknowledging
> that:
>
>
>
>1. The SPRING working group is adopting a document that has multiple
>SRv6 Endpoint behaviors.
>2. The document is a “living” document; it may change as it goes
>through review and analysis by the SPRING working group.
>3. All open discussion points raised on our mailing list MUST be
>addressed BEFORE said document is allowed to progress from the working
>group to publication. A list of these discussion points will be documented
>in the WG document and maintained by the document editor in conjunction
>with the chairs.
>4. If this document is adopted by the working group, the chairs
>specify as part of the adoption call that the following text describing an
>open issue be added to the document in the above-described open issues
>section:
>   - "Given that the working group has said that it wants to
>   standardize one data plane solution, and given that the document 
> contains
>   multiple SRv6 EndPoint behaviors that some WG members have stated are
>   multiple data plane solutions, the working group will address whether 
> this
>   is valid and coherent with its one data plane solution objective.".
>
>
>
> Please consider the above guidelines as you decide on whether to support
> or not this WG adoption. Please express clearly your reasoning for
> support/non-support as well as any open discussion points you would like
> addressed should the document be adopted into the working group.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>


-- 

*André Béliveau*

Director Product Management

M : +1 514-502-9592

andre.beliv...@noviflow.com



www.noviflow.com
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Bao,Guixin]

Hi, Dear WG

I support the adoption of this draft.

From the user point of view, I think the CSID proposes a highly efficient way  
for SRv6 compression, and it can make the network programming model (RFC8986) 
be easier to deploy. CSID is just adding the next and replace flavors and still 
maintain a single SRv6 based data plane.

Thanks.

Guixin Bao
Baidu  Network Chief Architect

发件人: spring  代表 James Guichard 

日期: 2021年10月1日 星期五 22:04
收件人: SPRING WG 
抄送: "spring-cha...@ietf.org" 
主题: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Shay Zadok]

Dear WG,

We would like to update on the production support by the StrataDNX
products of both flavors REPLACE and NEXT as defined in CSID draft, as well
as non-compressed "Classic" SRv6.
StrataDNX products include:
Jericho2/Jericho2c/Qumran2c/Qumran2a/Qumran2u/Qumran2n/Jericho2c+ and any
future device

This support keeps:
1. Single and unified data-plane uCode, programmed using high level language
2. Single data-plane API
3. Concurrent/Simultaneous support of all three techniques based on a
per-packet behavior
4. Concurrent/Simultaneous support of all three techniques inside of the
same SRv6 Header
5. In all three techniques the following is already supported
concurrently/simultaneously
and in production
1. SRv6 main behaviors - compliant with *rfc8986*
2. SRv6 insert behaviors - compliant with *draft-srv6-net-pgm-insertion*
3. SRv6 midpoint protection behaviors - compliant with
*draft-midpoint-protection*

All of the above is in production deployment in various published and
unpublished networks around the globe.
Our products are used by industry leading OEM (some of them published they
are using the StrataDNX products) and "pure" NOS vendors.

BRCM using Jericho2 participated in couple of interops that included some
mix of REPLACE-CSID, NEXT-CSID and non-compressed "Classic" SRv6 - and all
interops have ended successfully

Thanks & Regards,
Shay






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



Dear WG:



The chairs would like to express their appreciation for all the responses
received to our emails with reference to how the working group wishes to
move forward with respect to a solution for SRv6 compression.



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



Because of the above the chairs would like to issue a 2-week WG call for
adoption ending October 15th for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
but
with some clear guidelines as follows. By expressing support for adoption
of this document you are fully aware of and are acknowledging that:



   1. The SPRING working group is adopting a document that has multiple
   SRv6 Endpoint behaviors.
   2. The document is a “living” document; it may change as it goes through
   review and analysis by the SPRING working group.
   3. All open discussion points raised on our mailing list MUST be
   addressed BEFORE said document is allowed to progress from the working
   group to publication. A list of these discussion points will be documented
   in the WG document and maintained by the document editor in conjunction
   with the chairs.
   4. If this document is adopted by the working group, the chairs specify
   as part of the adoption call that the following text describing an open
   issue be added to the document in the above-described open issues section:


   - "Given that the working group has said that it wants to standardize
  one data plane solution, and given that the document contains
multiple SRv6
  EndPoint behaviors that some WG members have stated are multiple
data plane
  solutions, the working group will address whether this is valid and
  coherent with its one data plane solution objective.".



Please consider the above guidelines as you decide on whether to support or
not this WG adoption. Please express clearly your reasoning for
support/non-support as well as any open discussion points you would like
addressed should the document be adopted into the working group.



Thanks!



Jim, Bruno & Joel

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Takuya Miyasaka]

Hi,

I support the adoption of this draft.

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

On 2021/10/01 23:04, 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.


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 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 
 
but with some clear guidelines as follows. By expressing support for 
adoption of this document you are fully aware of and are acknowledging 
that:


 1. The SPRING working group is adopting a document that has multiple
SRv6 Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes
through review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be
addressed BEFORE said document is allowed to progress from the
working group to publication. A list of these discussion points
will be documented in the WG document and maintained by the
document editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs
specify as part of the adoption call that the following text
describing an open issue be added to the document in the
above-described open issues section:
  * "Given that the working group has said that it wants to
standardize one data plane solution, and given that the
document contains multiple SRv6 EndPoint behaviors that some
WG members have stated are multiple data plane solutions, the
working group will address whether this is valid and coherent
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to 
support or not this WG adoption. Please express clearly your reasoning 
for support/non-support as well as any open discussion points you 
would like addressed should the document be adopted into the working 
group.


Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Tetsuya Murakami]

Dear WG,

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

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  
> 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.
>  
> 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 
> 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:
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors.
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group.
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the chairs.
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org 
> https://www.ietf.org/mailman/listinfo/spring 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Paul Mattes]

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

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 9:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Joel M. Halpern]

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.


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


Dear WG:

The chairs would like to express their appreciation for all the 
responses received to our emails with reference to how the working group 
wishes to move forward with respect to a solution for SRv6 compression.


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


Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 
 
but with some clear guidelines as follows. By expressing support for 
adoption of this document you are fully aware of and are acknowledging 
that:


 1. The SPRING working group is adopting a document that has multiple
SRv6 Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes
through review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be
addressed BEFORE said document is allowed to progress from the
working group to publication. A list of these discussion points will
be documented in the WG document and maintained by the document
editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs specify
as part of the adoption call that the following text describing an
open issue be added to the document in the above-described open
issues section:
  * "Given that the working group has said that it wants to
standardize one data plane solution, and given that the document
contains multiple SRv6 EndPoint behaviors that some WG members
have stated are multiple data plane solutions, the working group
will address whether this is valid and coherent with its one
data plane solution objective.".

Please consider the above guidelines as you decide on whether to support 
or not this WG adoption. Please express clearly your reasoning for 
support/non-support as well as any open discussion points you would like 
addressed should the document be adopted into the working group.


Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Chengli (Cheng Li)]

Hi SPRING，

Sorry for the late response due to the National days break. It seems like I 
miss a lot of discussion, and it did cost me a lot of time to read all the 
threads.

As a member of the design team, and a person who participates in IETF SR 
standards for a long time,  I know who how difficult for us to get here. Many 
thanks for the contributions from anyone.

From the outputs of DT team, we know that CSID meets all the requirements and 
provide the best performance. As an author of CSID draft, I can say that over 
10 vendors have implemented CSID, which proves that CSID has been adopted by 
the industry very well. Therefore, no matter from the aspect of rough consensus 
and running code, I do think we should adopt CSID and it is the right way for 
sure. Also, from many polls in the mailing list, we also see the consensus of 
using CSID as the basis of SRv6 compression standard.

Till now, many our customers have chosen the CSID as the SRv6 compression 
solution, and some inter-op test and trial deployment have been finished even 
one year ago in CMCC’s lab and live network, and we will have more product 
network deployments in the near future. It proves that CSID can work very well 
in the product network. Many thanks for the customers and partners who choose 
CSID in their networks and products.

There may be some issues discussed in the mailing list, that is good! It also 
proves that people are interested in the topic as well, we are very welcome 
anyone to make the contributions to the solution, and let’s do it together to 
produce a good solution for the industry, that is what we are doing all the 
long way. Therefore, also thanks to the people provide comments in the mailing 
list. Will reply to the mailing list to answer the questions ASAP.

At the end, as an author, the member of the design team, and a person who focus 
on SR standards for a long time, I strongly support the CSID adoption.

Respect,
Cheng



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

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[zhu...@chinatelecom.cn]

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



zhu...@chinatelecom.cn
 
From: James Guichard
Date: 2021-10-01 22:04
To: SPRING WG
CC: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.
 
Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that: 
 
The SPRING working group is adopting a document that has multiple SRv6 Endpoint 
behaviors. 
The document is a “living” document; it may change as it goes through review 
and analysis by the SPRING working group. 
All open discussion points raised on our mailing list MUST be addressed BEFORE 
said document is allowed to progress from the working group to publication. A 
list of these discussion points will be documented in the WG document and 
maintained by the document editor in conjunction with the chairs. 
If this document is adopted by the working group, the chairs specify as part of 
the adoption call that the following text describing an open issue be added to 
the document in the above-described open issues section:
"Given that the working group has said that it wants to standardize one data 
plane solution, and given that the document contains multiple SRv6 EndPoint 
behaviors that some WG members have stated are multiple data plane solutions, 
the working group will address whether this is valid and coherent with its one 
data plane solution objective.".
 
Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[David Melman]

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.

I support the WG adoption of the draft.

David

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 5:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
Subject: [EXT] [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

External Email

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Weiqiang Cheng]

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:spring-boun...@ietf.org] 代表 James Guichard
发送时间: 2021年10月1日 22:05
收件人: SPRING WG
抄送: spring-cha...@ietf.org
主题: [spring] WG Adoption call for
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres
sion/

 

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

 

 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Francois Clad (fclad)]

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 
Date: Friday, 8 October 2021 at 22:21
To: Francois Clad (fclad) 
Cc: Robert Raszuk , Ron Bonica 
, James Guichard 
, SPRING WG , 
spring-cha...@ietf.org 
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) 
mailto:fc...@cisco.com>> 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

From: Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Thursday, 7 October 2021 at 20:15
To: Francois Clad (fclad) mailto:fc...@cisco.com>>
Cc: Robert Raszuk mailto:rob...@raszuk.net>>, Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>, 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>
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) 
mailto:fc...@cisco.com>> 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

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

[Francois Clad (fclad)]

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 
Date: Sunday, 10 October 2021 at 06:06
To: Francois Clad (fclad) , James Guichard 
, SPRING WG 
Cc: spring-cha...@ietf.org 
Subject: Re: WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
Hi Francois,

Thanks for your responses. Please see inline..

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

I am assuming that the border node is an SR segment endpoint node in your 
question.
[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

From: spring  on behalf of Tarek Saad 

Date: Friday, 8 October 2021 at 06:06
To: James Guichard , SPRING WG 
Cc: spring-cha...@ietf.org 
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.

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


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 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

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

[Kentaro Ebisawa]

Dear SPRING Working Group,

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

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


On 2021/10/01 23:04, 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.

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 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 

 but with some clear guidelines as follows. By expressing support for adoption of 
this document you are fully aware of and are acknowledging that:

 1. The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
  * "Given that the working group has said that it wants to standardize one data 
plane solution, and given that the document contains multiple SRv6 EndPoint behaviors 
that some WG members have stated are multiple data plane solutions, the working group 
will address whether this is valid and coherent with its one data plane solution 
objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Severin Dellsperger]

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


From: spring  on behalf of James Guichard 

Sent: Friday, October 1, 2021 4:04 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.



Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:



  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".



Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.



Thanks!



Jim, Bruno & Joel




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Julian Klaiber]

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



From: spring  on behalf of James Guichard 

Sent: Friday, 1 October 2021 16:04
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.



Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:



  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".



Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.



Thanks!



Jim, Bruno & Joel




___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Sudarshan, Reshma]

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

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 7:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Andrea Mayer]

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 +
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. 
> 
>  
> 
> The apparent inclination of the working group is to use 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
> 
>  
> 
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that: 
> 
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors. 
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group. 
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the 
> chairs. 
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> 
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
> 
>  
> 
> Thanks!
> 
>  
> 
> Jim, Bruno & Joel
> 
>  
> 
>  
> 


-- 
Andrea Mayer 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Paolo Lungaroni]

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

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 
>  ha scritto:
> 
> Dear WG:
>  
> The chairs would like to express their appreciation for all the responses 
> received to our emails with reference to how the working group wishes to move 
> forward with respect to a solution for SRv6 compression. 
>  
> The apparent inclination of the working group is to use 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
>  
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that: 
>  
>   • The SPRING working group is adopting a document that has multiple 
> SRv6 Endpoint behaviors. 
>   • The document is a “living” document; it may change as it goes through 
> review and analysis by the SPRING working group. 
>   • All open discussion points raised on our mailing list MUST be 
> addressed BEFORE said document is allowed to progress from the working group 
> to publication. A list of these discussion points will be documented in the 
> WG document and maintained by the document editor in conjunction with the 
> chairs. 
>   • If this document is adopted by the working group, the chairs specify 
> as part of the adoption call that the following text describing an open issue 
> be added to the document in the above-described open issues section:
>   • "Given that the working group has said that it wants to 
> standardize one data plane solution, and given that the document contains 
> multiple SRv6 EndPoint behaviors that some WG members have stated are 
> multiple data plane solutions, the working group will address whether this is 
> valid and coherent with its one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Pier Luigi Ventre]

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  
> 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. 
>  
> The apparent inclination of the working group is to use 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  
> 
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
>  
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  
> 
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that: 
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors. 
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group. 
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the 
> chairs. 
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org 
> https://www.ietf.org/mailman/listinfo/spring 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Thomas.Graf]

Dear WG,

I support the adoption of draft 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 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

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 4:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 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




smime.p7s
Description: S/MIME Cryptographic Signature
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Dhruv Dhody]

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

On Fri, Oct 1, 2021 at 7:35 PM James Guichard <
james.n.guich...@futurewei.com> 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.
>
>
>
> The apparent inclination of the working group is to use
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> as the basis for its compression standardization work. That is part of what
> this email attempts to confirm.
>
>
>
> Because of the above the chairs would like to issue a 2-week WG call for
> adoption ending October 15th for
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> but with some clear guidelines as follows. By expressing support for
> adoption of this document you are fully aware of and are acknowledging
> that:
>
>
>
>1. The SPRING working group is adopting a document that has multiple
>SRv6 Endpoint behaviors.
>2. The document is a “living” document; it may change as it goes
>through review and analysis by the SPRING working group.
>3. All open discussion points raised on our mailing list MUST be
>addressed BEFORE said document is allowed to progress from the working
>group to publication. A list of these discussion points will be documented
>in the WG document and maintained by the document editor in conjunction
>with the chairs.
>4. If this document is adopted by the working group, the chairs
>specify as part of the adoption call that the following text describing an
>open issue be added to the document in the above-described open issues
>section:
>   - "Given that the working group has said that it wants to
>   standardize one data plane solution, and given that the document 
> contains
>   multiple SRv6 EndPoint behaviors that some WG members have stated are
>   multiple data plane solutions, the working group will address whether 
> this
>   is valid and coherent with its one data plane solution objective.".
>
>
>
> Please consider the above guidelines as you decide on whether to support
> or not this WG adoption. Please express clearly your reasoning for
> support/non-support as well as any open discussion points you would like
> addressed should the document be adopted into the working group.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Wanghaibo (Rainsword)]

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

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Satoru Matsushima]

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  
> 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.
>  
> The apparent inclination of the working group is to use 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
>  
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that:
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors.
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group.
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the chairs.
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Mach Chen]

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

From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Primadi Hendra Kusuma]

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,

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 9:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[David Lo Bascio]

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
david.lobas...@uniroma1.it



Il 01/10/21 16:04, James Guichard ha scritto:


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 15^th 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




--

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.
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Mark Smith]

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.

On Sat, 2 Oct 2021 at 00:05, 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.
>
>
>
> The apparent inclination of the working group is to use 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
>
>
>
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that:
>
>
>
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors.
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group.
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the chairs.
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
>
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>
>
>
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Mike Koldychev (mkoldych)]

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.

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Carmine Scarpitta]

Hi WG, 

 

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

 

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

 

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 4:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

 

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that: 

 

1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors. 
2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group. 
3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs. 
4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

*   "Given that the working group has said that it wants to standardize one 
data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

 

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[liujh . cc]

Hi,  AllI’d like to  support the adoption of the draft https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/For CSID is a efficient solution based on the SRv6 data plane. And it provides a flexible choice of flavors when apply in different kinds of scenarios.  Best Wishes!Jianhua Liuhttp://www.fiberhome.com

 

From: spring  on behalf of James Guichard 
Date: Friday, October 1, 2021 at 4:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 as the basis for its compression standardization work. That is part of what this email attempts to confirm.


Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:




1.       The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.


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


3.       All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from
 the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs.


4.       If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text
 describing an open issue be added to the document in the above-described open issues section:


·         "Given that the working group has said that it wants to standardize one data plane solution, and given that the document
 contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.".


Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning
 for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.


Thanks!


Jim, Bruno & Joel



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Marco Bonola]

Dear all,

I support the adoption of this draft.

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


On 01/10/21 16:04, 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.


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 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 
but with some clear guidelines as follows. By expressing support for 
adoption of this document you are fully aware of and are acknowledging 
that:


 1. The SPRING working group is adopting a document that has multiple
SRv6 Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes
through review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be
addressed BEFORE said document is allowed to progress from the
working group to publication. A list of these discussion points
will be documented in the WG document and maintained by the
document editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs
specify as part of the adoption call that the following text
describing an open issue be added to the document in the
above-described open issues section:
  * "Given that the working group has said that it wants to
standardize one data plane solution, and given that the
document contains multiple SRv6 EndPoint behaviors that some
WG members have stated are multiple data plane solutions, the
working group will address whether this is valid and coherent
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to 
support or not this WG adoption. Please express clearly your reasoning 
for support/non-support as well as any open discussion points you 
would like addressed should the document be adopted into the working 
group.


Thanks!

Jim, Bruno & Joel
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Francesco Lombardo]

Hi WG,

I support the adoption of CSID draft.

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

On 01/10/21 16:04, 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.


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 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 
 
but with some clear guidelines as follows. By expressing support for 
adoption of this document you are fully aware of and are acknowledging 
that:


 1. The SPRING working group is adopting a document that has multiple
SRv6 Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes
through review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be
addressed BEFORE said document is allowed to progress from the
working group to publication. A list of these discussion points
will be documented in the WG document and maintained by the
document editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs
specify as part of the adoption call that the following text
describing an open issue be added to the document in the
above-described open issues section:
  * "Given that the working group has said that it wants to
standardize one data plane solution, and given that the
document contains multiple SRv6 EndPoint behaviors that some
WG members have stated are multiple data plane solutions, the
working group will address whether this is valid and coherent
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to 
support or not this WG adoption. Please express clearly your reasoning 
for support/non-support as well as any open discussion points you 
would like addressed should the document be adopted into the working 
group.


Thanks!

Jim, Bruno & Joel

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[DiVincenzo, Mike]

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: mike.divince...@wwt.com  |  CCIE #9358



On Oct 1, 2021, at 10:05 AM, James Guichard 
mailto:james.n.guich...@futurewei.com>> 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.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".


Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Sébastien Parisot]

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" 
> À: "SPRING WG List" 
> Cc: spring-cha...@ietf.org
> 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/

> 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://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 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:
> 
> 
> 
>1. The SPRING working group is adopting a document that has multiple SRv6
>Endpoint behaviors.
>2. The document is a “living” document; it may change as it goes through 
> review
>and analysis by the SPRING working group.
>3. All open discussion points raised on our mailing list MUST be addressed
>BEFORE said document is allowed to progress from the working group to
>publication. A list of these discussion points will be documented in the WG
>document and maintained by the document editor in conjunction with the 
> chairs.
>4. If this document is adopted by the working group, the chairs specify as 
> part
>of the adoption call that the following text describing an open issue be 
> added
>to the document in the above-described open issues section:
> 
> 
>* "Given that the working group has said that it wants to standardize 
> one data
>plane solution, and given that the document contains multiple SRv6 
> EndPoint
>behaviors that some WG members have stated are multiple data plane 
> solutions,
>the working group will address whether this is valid and coherent with 
> its one
>data plane solution objective.".
> 
> 
> 
> 
> Please consider the above guidelines as you decide on whether to support or 
> not
> this WG adoption. Please express clearly your reasoning for 
> support/non-support
> as well as any open discussion points you would like addressed should the
> document be adopted into the working group.
> 
> 
> 
> Thanks!
> 
> 
> 
> Jim, Bruno & Joel
> 
> 
> 
> 
> 
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Kang, Haitao]

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 
mailto:james.n.guich...@futurewei.com>> 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.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Gaurav Dawra]

Dear WG and Chairs,

With multiple vendor implementations and interops. The draft is for SRv6 
compression based on the single SRv6 data plane

I strongly support its adoption

Gaurav
Linkedin

> On Oct 10, 2021, at 10:48 PM, Keyur Patel  wrote:
> 
> Dear WG and the WG Chairs,
>  
> Network programming model (RFC8986) defines multiple flavors for End, End.X, 
> and End.T SIDs. CSID draft builds on it with next and replace flavors for 
> these SIDs, optimized for 16 bit and 32 bit SID sizes, respectively. This is 
> just like PSP, USP and USD flavors defined in RFC8986 to cover different 
> deployment scenarios.
>  
> We at Arrcus have implemented CSID solution and also have participated in 
> multivendor interop for the solution.
>  
> I strongly support the adoption.
>  
> Best Regards,
> Keyur
>  
>  
> From: spring  on behalf of "Zafar Ali (zali)" 
> 
> Date: Monday, October 4, 2021 at 8:50 AM
> To: James Guichard , SPRING WG 
> 
> Cc: "Zafar Ali (zali)" , "spring-cha...@ietf.org" 
> 
> Subject: Re: [spring] WG Adoption call for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  
> Dear WG and the chairs,
>  
> I strongly support the adoption call
>  
> About the matter in the email, the WG has defined a single data plane 
> solution, i.e., SRv6 (RFC8402, RFC8754, and RFC8986).
> SRv6 as per the inherent nature of the network programming model (RFC8996) 
> already defines multiple standardized behaviors.
> Clearly, CSID is a single solution based on the SRv6 data plane.
>  
> Thanks
>  
> Regards … Zafar 
>  
>  
> From: spring  on behalf of James Guichard 
> 
> Date: Friday, October 1, 2021 at 10:05 AM
> To: SPRING WG 
> Cc: "spring-cha...@ietf.org" 
> 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/
>  as the basis for its compression standardization work. That is part of what 
> this email attempts to confirm.
>  
> Because of the above the chairs would like to issue a 2-week WG call for 
> adoption ending October 15th for 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that:
>  
> 1.   The SPRING working group is adopting a document that has multiple 
> SRv6 Endpoint behaviors.
> 2.   The document is a “living” document; it may change as it goes 
> through review and analysis by the SPRING working group.
> 3.   All open discussion points raised on our mailing list MUST be 
> addressed BEFORE said document is allowed to progress from the working group 
> to publication. A list of these discussion points will be documented in the 
> WG document and maintained by the document editor in conjunction with the 
> chairs.
> 4.   If this document is adopted by the working group, the chairs specify 
> as part of the adoption call that the following text describing an open issue 
> be added to the document in the above-described open issues section:
> · "Given that the working group has said that it wants to standardize 
> one data plane solution, and given that the document contains multiple SRv6 
> EndPoint behaviors that some WG members have stated are multiple data plane 
> solutions, the working group will address whether this is valid and coherent 
> with its one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Rishabh Parekh]

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

On Fri, Oct 1, 2021 at 7:05 AM James Guichard <
james.n.guich...@futurewei.com> 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.
>
>
>
> The apparent inclination of the working group is to use
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> as the basis for its compression standardization work. That is part of what
> this email attempts to confirm.
>
>
>
> Because of the above the chairs would like to issue a 2-week WG call for
> adoption ending October 15th for
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> but with some clear guidelines as follows. By expressing support for
> adoption of this document you are fully aware of and are acknowledging
> that:
>
>
>
>1. The SPRING working group is adopting a document that has multiple
>SRv6 Endpoint behaviors.
>2. The document is a “living” document; it may change as it goes
>through review and analysis by the SPRING working group.
>3. All open discussion points raised on our mailing list MUST be
>addressed BEFORE said document is allowed to progress from the working
>group to publication. A list of these discussion points will be documented
>in the WG document and maintained by the document editor in conjunction
>with the chairs.
>4. If this document is adopted by the working group, the chairs
>specify as part of the adoption call that the following text describing an
>open issue be added to the document in the above-described open issues
>section:
>   - "Given that the working group has said that it wants to
>   standardize one data plane solution, and given that the document 
> contains
>   multiple SRv6 EndPoint behaviors that some WG members have stated are
>   multiple data plane solutions, the working group will address whether 
> this
>   is valid and coherent with its one data plane solution objective.".
>
>
>
> Please consider the above guidelines as you decide on whether to support
> or not this WG adoption. Please express clearly your reasoning for
> support/non-support as well as any open discussion points you would like
> addressed should the document be adopted into the working group.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Ron Bonica]

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




Juniper Business Use Only
From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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 chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Linda Dunbar]

With multiple vendors having implemented the solution, I strongly support the 
adoption of draft-filsfilscheng-spring-srv6-srh-compression.

Linda Dunbar

From: spring  On Behalf Of Keyur Patel
Sent: Monday, October 11, 2021 12:48 AM
To: Zafar Ali (zali) ; James Guichard 
; SPRING WG 
Cc: spring-cha...@ietf.org; Zafar Ali (zali) 
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG and the WG Chairs,

Network programming model (RFC8986) defines multiple flavors for End, End.X, 
and End.T SIDs. CSID draft builds on it with next and replace flavors for these 
SIDs, optimized for 16 bit and 32 bit SID sizes, respectively. This is just 
like PSP, USP and USD flavors defined in RFC8986 to cover different deployment 
scenarios.

We at Arrcus have implemented CSID solution and also have participated in 
multivendor interop for the solution.

I strongly support the adoption.

Best Regards,
Keyur


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of "Zafar Ali (zali)" 
mailto:zali=40cisco@dmarc.ietf.org>>
Date: Monday, October 4, 2021 at 8:50 AM
To: James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>
Cc: "Zafar Ali (zali)" mailto:z...@cisco.com>>, 
"spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>" 
mailto:spring-cha...@ietf.org>>
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG and the chairs,

I strongly support the adoption call

About the matter in the email, the WG has defined a single data plane solution, 
i.e., SRv6 (RFC8402, RFC8754, and RFC8986).
SRv6 as per the inherent nature of the network programming model (RFC8996) 
already defines multiple standardized behaviors.
Clearly, CSID is a single solution based on the SRv6 data plane.

Thanks

Regards ... Zafar


From: spring mailto:spring-boun...@ietf.org>> on 
behalf of James Guichard 
mailto:james.n.guich...@futurewei.com>>
Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG mailto:spring@ietf.org>>
Cc: "spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>" 
mailto:spring-cha...@ietf.org>>
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=04%7C01%7Clinda.dunbar%40futurewei.com%7C8de269e773ca4459499408d98c7ab2cf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637695280917116632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=0GGK8CBENHCpOS2TdHfbxp9ph9k8R9dXMDmJTQWyBUI%3D=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=04%7C01%7Clinda.dunbar%40futurewei.com%7C8de269e773ca4459499408d98c7ab2cf%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637695280917116632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000=0GGK8CBENHCpOS2TdHfbxp9ph9k8R9dXMDmJTQWyBUI%3D=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:


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 
on

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

[duzongp...@foxmail.com]

Hi, all

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

Best Regards
Zongpeng Du


duzongp...@foxmail.com & duzongp...@chinamobile.com
 
From: James Guichard
Date: 2021-10-01 22:04
To: SPRING WG
CC: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.
 
Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that: 
 
The SPRING working group is adopting a document that has multiple SRv6 Endpoint 
behaviors. 
The document is a “living” document; it may change as it goes through review 
and analysis by the SPRING working group. 
All open discussion points raised on our mailing list MUST be addressed BEFORE 
said document is allowed to progress from the working group to publication. A 
list of these discussion points will be documented in the WG document and 
maintained by the document editor in conjunction with the chairs. 
If this document is adopted by the working group, the chairs specify as part of 
the adoption call that the following text describing an open issue be added to 
the document in the above-described open issues section:
"Given that the working group has said that it wants to standardize one data 
plane solution, and given that the document contains multiple SRv6 EndPoint 
behaviors that some WG members have stated are multiple data plane solutions, 
the working group will address whether this is valid and coherent with its one 
data plane solution objective.".
 
Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[liupeng...@outlook.com]

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)



liupeng...@outlook.com
 
From: James Guichard
Date: 2021-10-01 22:04
To: SPRING WG
CC: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.
 
Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that: 
 
The SPRING working group is adopting a document that has multiple SRv6 Endpoint 
behaviors. 
The document is a “living” document; it may change as it goes through review 
and analysis by the SPRING working group. 
All open discussion points raised on our mailing list MUST be addressed BEFORE 
said document is allowed to progress from the working group to publication. A 
list of these discussion points will be documented in the WG document and 
maintained by the document editor in conjunction with the chairs. 
If this document is adopted by the working group, the chairs specify as part of 
the adoption call that the following text describing an open issue be added to 
the document in the above-described open issues section:
"Given that the working group has said that it wants to standardize one data 
plane solution, and given that the document contains multiple SRv6 EndPoint 
behaviors that some WG members have stated are multiple data plane solutions, 
the working group will address whether this is valid and coherent with its one 
data plane solution objective.".
 
Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Peter Psenak]

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


On 01/10/2021 16:04, 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.


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 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 
but with some clear guidelines as follows. By expressing support for 
adoption of this document you are fully aware of and are acknowledging 
that:


 1. The SPRING working group is adopting a document that has multiple
SRv6 Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes
through review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be
addressed BEFORE said document is allowed to progress from the
working group to publication. A list of these discussion points will
be documented in the WG document and maintained by the document
editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs specify
as part of the adoption call that the following text describing an
open issue be added to the document in the above-described open
issues section:
  * "Given that the working group has said that it wants to
standardize one data plane solution, and given that the document
contains multiple SRv6 EndPoint behaviors that some WG members
have stated are multiple data plane solutions, the working group
will address whether this is valid and coherent with its one
data plane solution objective.".

Please consider the above guidelines as you decide on whether to support 
or not this WG adoption. Please express clearly your reasoning for 
support/non-support as well as any open discussion points you would like 
addressed should the document be adopted into the working group.


Thanks!

Jim, Bruno & Joel



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Huzhibo]

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
From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Tianran Zhou]

Hi Chairs and WG,

I strongly support the adoption of this draft.

As far as I know, there are already multiple vendors(10+) support CSID and 
passed the interoperation test.
I followed the DT for a while. CSID as a SRv6 native solution, shows great 
advantages than CRH.
This draft is mature enough to be adopted by the WG, as the baseline for 
further development.

Cheers,
Tianran


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

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Laurent Metzger]

Dear WG



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


I have been using the SRv6 encapsulation in various applied research projects 
at my university and I have mostly experience with the NEXT-C-SID flavor in 
projects related to SR-TE and service chaining.


I am happy about the fact that the draft describes multiple SRv6 EndPoint 
behaviors and adds the Combined NEXT-and-REPLACE-C-SID flavor in order to allow 
the support of different deployment use cases. It is adding a new flavor, in 
the same way the Penultimate Segment Pop (PSP), Ultimate Segment Pop (USP), and 
Ultimate Segment Decapsulation (USD) of the SRH are flavors of the End, End.X, 
and End.T behaviors in the RFC8986.


I consider that the draft is proposing a single SRv6 based dataplane that is 
consistent with RFC8986 and I therefore support the WG adoption of the draft.


Best Regards,

Laurent


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 4:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


1.   The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.

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

3.   All open discussion points raised on our mailing list MUST be 
addressed BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.

4.   If this document is adopted by the working group, the chairs specify 
as part of the adoption call that the following text describing an open issue 
be added to the document in the above-described open issues section:

· "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Keyur Patel]

Dear WG and the WG Chairs,

Network programming model (RFC8986) defines multiple flavors for End, End.X, 
and End.T SIDs. CSID draft builds on it with next and replace flavors for these 
SIDs, optimized for 16 bit and 32 bit SID sizes, respectively. This is just 
like PSP, USP and USD flavors defined in RFC8986 to cover different deployment 
scenarios.

We at Arrcus have implemented CSID solution and also have participated in 
multivendor interop for the solution.

I strongly support the adoption.

Best Regards,
Keyur


From: spring  on behalf of "Zafar Ali (zali)" 

Date: Monday, October 4, 2021 at 8:50 AM
To: James Guichard , SPRING WG 
Cc: "Zafar Ali (zali)" , "spring-cha...@ietf.org" 

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

Dear WG and the chairs,

I strongly support the adoption call

About the matter in the email, the WG has defined a single data plane solution, 
i.e., SRv6 (RFC8402, RFC8754, and RFC8986).
SRv6 as per the inherent nature of the network programming model (RFC8996) 
already defines multiple standardized behaviors.
Clearly, CSID is a single solution based on the SRv6 data plane.

Thanks

Regards … Zafar


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG 
Cc: "spring-cha...@ietf.org" 
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


1.   The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.

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

3.   All open discussion points raised on our mailing list MUST be 
addressed BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.

4.   If this document is adopted by the working group, the chairs specify 
as part of the adoption call that the following text describing an open issue 
be added to the document in the above-described open issues section:

· "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ]]

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
luc-fabrice.ndi...@mtn.com
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  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 3:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Tarek Saad]

Hi Francois,

Thanks for your responses. Please see inline..

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

I am assuming that the border node is an SR segment endpoint node in your 
question.
[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

From: spring  on behalf of Tarek Saad 

Date: Friday, 8 October 2021 at 06:06
To: James Guichard , SPRING WG 
Cc: spring-cha...@ietf.org 
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.

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


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 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

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

[Ahmed MostafaSaleh ElSawaf]

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

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 4:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 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



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).
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Xiejingrong (Jingrong)]

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


From: spring [mailto:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Dongjie (Jimmy)]

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:spring-boun...@ietf.org] On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Mankamana Mishra (mankamis)]

I have read the draft-filsfilscheng-spring-srv6-srh-compression, and it  is a 
single SRv6 data plane compliant solution with the next and replace flavors 
added for the SRv6 compression.

I strongly support the WG adoption of the draft.

Mankamana
From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG 
Cc: "spring-cha...@ietf.org" 
Subject: [EXT][spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Greg Mirsky]

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) 
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
>
>
>
> *From: *Greg Mirsky 
> *Date: *Thursday, 7 October 2021 at 20:15
> *To: *Francois Clad (fclad) 
> *Cc: *Robert Raszuk , Ron Bonica  40juniper@dmarc.ietf.org>, James Guichard <
> james.n.guich...@futurewei.com>, SPRING WG ,
> spring-cha...@ietf.org 
> *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) 
> 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 
> *Date: *Wednesday, 6 October 2021 at 19:19
> *To: *Francois Clad (fclad) 
> *Cc: *Robert Raszuk , Ron Bonica  40juniper@dmarc.ietf.org>, James Guichard <
> james.n.guich...@futurewei.com>, SPRING WG ,
> spring-cha...@ietf.org 
> *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 hap

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

[Swadesh Agrawal (swaagraw)]

Hi Chairs, WG,

RFC8986 defines multiple flavors for the End, End.X, and End.T SIDs. CSID draft 
adds next and replace flavors for these SIDs for SRv6 compression in 
conformance to RFC8986. CSID is a single SRv6 based data plane solution

I strongly support the WG adoption call.

Regards
Swadesh


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 7:04 AM
To: SPRING WG 
Cc: "spring-cha...@ietf.org" 
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Parag Kaneriya]

I object the adoption of this document

-Parag

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 7:35 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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 chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Francois Clad (fclad)]

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  on behalf of Tarek Saad 

Date: Friday, 8 October 2021 at 06:06
To: James Guichard , SPRING WG 
Cc: spring-cha...@ietf.org 
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.

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


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Francois Clad (fclad)]

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 
Date: Thursday, 7 October 2021 at 20:15
To: Francois Clad (fclad) 
Cc: Robert Raszuk , Ron Bonica 
, James Guichard 
, SPRING WG , 
spring-cha...@ietf.org 
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) 
mailto:fc...@cisco.com>> 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 mailto:gregimir...@gmail.com>>
Date: Wednesday, 6 October 2021 at 19:19
To: Francois Clad (fclad) mailto:fc...@cisco.com>>
Cc: Robert Raszuk mailto:rob...@raszuk.net>>, Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>, 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>
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) 
mailto:fc...@cisco.com>> 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 mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>, 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>
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 

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

[Melchior Aelmans]

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

On Fri, Oct 1, 2021 at 10:55 PM Tony Li  wrote:

>
> +1
>
> I object to the adoption.
>
> Tony
>
>
> On Oct 1, 2021, at 1:43 PM, Andrew Alston <
> Andrew.Alston=40liquidtelecom@dmarc.ietf.org> 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 
> *Date: *Friday, 1 October 2021 at 23:21
> *To: *James Guichard , SPRING WG <
> spring@ietf.org>
> *Cc: *spring-cha...@ietf.org 
> *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  on behalf of James Guichard <
> james.n.guich...@futurewei.com>
> *Date: *Friday, 1 October 2021 at 17:05
> *To: *SPRING WG 
> *Cc: *spring-cha...@ietf.org 
> *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/
>  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 cle

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

[bruno.decraene]

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

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


On Oct 1, 2021, at 07:04, James Guichard 
mailto:james.n.guich...@futurewei.com>> 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.

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


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring


_

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.

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[James Guichard]

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

From: Andrew Alston 
Sent: Friday, October 8, 2021 11:23 AM
To: James Guichard ; SPRING WG 
Cc: spring-cha...@ietf.org
Subject: RE: WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

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

From: spring mailto:spring-boun...@ietf.org>> On 
Behalf Of James Guichard
Sent: Friday, October 1, 2021 5:05 PM
To: SPRING WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
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=04%7C01%7Cjames.n.guichard%40futurewei.com%7Cd73ddcb23a224377961208d98a6f85d1%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637693033882878589%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=qVc1JtbYU0DHrh6XcbfMARecW8yLiL05zpsx1itMk2o%3D=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=04%7C01%7Cjames

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

[Andrew Alston]

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

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 5:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 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 

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

[Srihari Sangli]

Hello Chairs,

This document describes 3 behaviours for SID and this in contradiction to what 
was discussed on SPRING alias about adopting one behaviour for which there was 
overwhelming response.

I strongly object the adoption of this draft.

srihari…


On 01/10/21, 7:35 PM spring on behalf of James Guichard from 
spring-boun...@ietf.org on behalf of 
james.n.guich...@futurewei.com said >

[External Email. Be cautious of content]

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




Juniper Business Use Only
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Martin Horneffer]

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


Am 01.10.21 um 16:04 schrieb James Guichard:

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 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 
 
but with some clear guidelines as follows. By expressing support for 
adoption of this document you are fully aware of and are acknowledging 
that:


 1. The SPRING working group is adopting a document that has multiple
SRv6 Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes
through review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be
addressed BEFORE said document is allowed to progress from the
working group to publication. A list of these discussion points will
be documented in the WG document and maintained by the document
editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs specify
as part of the adoption call that the following text describing an
open issue be added to the document in the above-described open
issues section:
  * "Given that the working group has said that it wants to
standardize one data plane solution, and given that the document
contains multiple SRv6 EndPoint behaviors that some WG members
have stated are multiple data plane solutions, the working group
will address whether this is valid and coherent with its one
data plane solution objective.".

Please consider the above guidelines as you decide on whether to support 
or not this WG adoption. Please express clearly your reasoning for 
support/non-support as well as any open discussion points you would like 
addressed should the document be adopted into the working group.


Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring



___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Giulio Sidoretti]

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  
> 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. 
>  
> 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 15thfor 
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
>  
> 
>  but with some clear guidelines as follows. By expressing support for 
> adoption of this document you are fully aware of and are acknowledging that: 
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors. 
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group. 
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the 
> chairs. 
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org 
> https://www.ietf.org/mailman/listinfo/spring 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Sales, Bernard (Nokia - BE/Antwerp)]

Hello,

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

Many Thanks,

-- Brd

From: spring  On Behalf Of James Guichard
Sent: Friday, October 1, 2021 4:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[gongli...@chinamobile.com]

Dear Chairs & WG，

I support the WG adoption of this draft.

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: spring-cha...@ietf.org
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.
 
Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that: 
 
The SPRING working group is adopting a document that has multiple SRv6 Endpoint 
behaviors. 
The document is a “living” document; it may change as it goes through review 
and analysis by the SPRING working group. 
All open discussion points raised on our mailing list MUST be addressed BEFORE 
said document is allowed to progress from the working group to publication. A 
list of these discussion points will be documented in the WG document and 
maintained by the document editor in conjunction with the chairs. 
If this document is adopted by the working group, the chairs specify as part of 
the adoption call that the following text describing an open issue be added to 
the document in the above-described open issues section:
"Given that the working group has said that it wants to standardize one data 
plane solution, and given that the document contains multiple SRv6 EndPoint 
behaviors that some WG members have stated are multiple data plane solutions, 
the working group will address whether this is valid and coherent with its one 
data plane solution objective.".
 
Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Tarek Saad]

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


From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Rakesh Gandhi (rgandhi)]

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  James Guichard
Inviato: venerdì 1 ottobre 2021 16:05
A: SPRING WG 
Cc: spring-cha...@ietf.org
Oggetto: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a “living” document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:
 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Kireeti Kompella]

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

> On Oct 1, 2021, at 07:04, 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.
>  
> 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 
> 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:
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors.
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group.
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the chairs.
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org 
> https://www.ietf.org/mailman/listinfo/spring 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Colby Barth]

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


—Colby

>> 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 
>> 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:
>>  
>> The SPRING working group is adopting a document that has multiple SRv6 
>> Endpoint behaviors.
>> The document is a “living” document; it may change as it goes through review 
>> and analysis by the SPRING working group.
>> All open discussion points raised on our mailing list MUST be addressed 
>> BEFORE said document is allowed to progress from the working group to 
>> publication. A list of these discussion points will be documented in the WG 
>> document and maintained by the document editor in conjunction with the 
>> chairs.
>> If this document is adopted by the working group, the chairs specify as part 
>> of the adoption call that the following text describing an open issue be 
>> added to the document in the above-described open issues section:
>> "Given that the working group has said that it wants to standardize one data 
>> plane solution, and given that the document contains multiple SRv6 EndPoint 
>> behaviors that some WG members have stated are multiple data plane 
>> solutions, the working group will address whether this is valid and coherent 
>> with its one data plane solution objective.".
>>  
>> Please consider the above guidelines as you decide on whether to support or 
>> not this WG adoption. Please express clearly your reasoning for 
>> support/non-support as well as any open discussion points you would like 
>> addressed should the document be adopted into the working group.
>>  
>> Thanks!
>>  
>> Jim, Bruno & Joel
>>  
>>  
>> ___
>> spring mailing list
>> spring@ietf.org 
>> https://www.ietf.org/mailman/listinfo/spring 
>> 
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Kireeti Kompella]

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

:K

> On Oct 1, 2021, at 07:04, 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.
>  
> 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 
> 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:
>  
> The SPRING working group is adopting a document that has multiple SRv6 
> Endpoint behaviors.
> The document is a “living” document; it may change as it goes through review 
> and analysis by the SPRING working group.
> All open discussion points raised on our mailing list MUST be addressed 
> BEFORE said document is allowed to progress from the working group to 
> publication. A list of these discussion points will be documented in the WG 
> document and maintained by the document editor in conjunction with the chairs.
> If this document is adopted by the working group, the chairs specify as part 
> of the adoption call that the following text describing an open issue be 
> added to the document in the above-described open issues section:
> "Given that the working group has said that it wants to standardize one data 
> plane solution, and given that the document contains multiple SRv6 EndPoint 
> behaviors that some WG members have stated are multiple data plane solutions, 
> the working group will address whether this is valid and coherent with its 
> one data plane solution objective.".
>  
> Please consider the above guidelines as you decide on whether to support or 
> not this WG adoption. Please express clearly your reasoning for 
> support/non-support as well as any open discussion points you would like 
> addressed should the document be adopted into the working group.
>  
> Thanks!
>  
> Jim, Bruno & Joel
>  
>  
> ___
> spring mailing list
> spring@ietf.org 
> https://www.ietf.org/mailman/listinfo/spring 
> 
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Bernier, Daniel]

Hi,

After re-reading the draft I strongly support its adoption.


  1.  Following the Design Team work stream, CSID proves conformant and optimal.
  2.  It allows for the flexibility of selecting the SRv6 data plane flavor 
(compressed or not) without changes to the architecture.
  3.  Has proven quite easy to implement with our existing HW platforms (in a 
matter of hours for some ASICs)
  4.  As my colleague Dan Voyer pointed out, we successfully deployed in 
production with live traffic.  And in a multi-vendor environment.

Thanks,

Dan B

From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG 
Cc: "spring-cha...@ietf.org" 
Subject: [EXT][spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

The chairs would like to express their appreciation for all the responses 
received to our emails with reference to how the working group wishes to move 
forward with respect to a solution for SRv6 compression.

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


1.   The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.

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

3.   All open discussion points raised on our mailing list MUST be 
addressed BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.

4.   If this document is adopted by the working group, the chairs specify 
as part of the adoption call that the following text describing an open issue 
be added to the document in the above-described open issues section:

· "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Greg Mirsky]

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) 
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 
> *Date: *Wednesday, 6 October 2021 at 19:19
> *To: *Francois Clad (fclad) 
> *Cc: *Robert Raszuk , Ron Bonica  40juniper....@dmarc.ietf.org>, James Guichard <
> james.n.guich...@futurewei.com>, SPRING WG ,
> spring-cha...@ietf.org 
> *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) 
> 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  on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> *Date: *Tuesday, 5 October 2021 at 23:37
> *To: *Robert Raszuk 
> *Cc: *Ron Bonica , James Guichard <
> james.n.guich...@futurewei.com>, SPRING WG ,
> spring-cha...@ietf.org 
> *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
>
>
>

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

[Ron Bonica]

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 
Sent: Wednesday, October 6, 2021 1:21 PM
To: Ron Bonica ; James Guichard 
; SPRING WG 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]


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




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



Juniper Business Use Only
From: spring <mailto:spring-boun...@ietf.org> On 
Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard 
<mailto:james.n.guich...@futurewei.com>; SPRING 
WG <mailto:spring@ietf.org>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
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$>

[External Email. Be cautious of content]


I support the adoption of this document.

  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


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.

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:


  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.

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

[Ron Bonica]

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) 
Sent: Tuesday, October 5, 2021 11:58 PM
To: Robert Raszuk ; Ron Bonica 
Cc: James Guichard ; SPRING WG 
; spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

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" 
mailto:spring-boun...@ietf.org>> 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.

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 
mailto:40juniper@dmarc.ietf.org>> 
wrote:
Pablo,

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

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

[Francois Clad (fclad)]

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 
Date: Wednesday, 6 October 2021 at 19:19
To: Francois Clad (fclad) 
Cc: Robert Raszuk , Ron Bonica 
, James Guichard 
, SPRING WG , 
spring-cha...@ietf.org 
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) 
mailto:fc...@cisco.com>> 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 mailto:spring-boun...@ietf.org>> on 
behalf of Greg Mirsky mailto:gregimir...@gmail.com>>
Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk mailto:rob...@raszuk.net>>
Cc: Ron Bonica 
mailto:40juniper@dmarc.ietf.org>>, 
James Guichard 
mailto:james.n.guich...@futurewei.com>>, SPRING 
WG mailto:spring@ietf.org>>, 
spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 
mailto:spring-cha...@ietf.org>>
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 
mailto:rob...@raszuk.net>> 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.

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 i

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

[Stefano Salsano]

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:

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 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 
 
but with some clear guidelines as follows. By expressing support for 
adoption of this document you are fully aware of and are acknowledging 
that:


 1. The SPRING working group is adopting a document that has multiple
SRv6 Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes
through review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be
addressed BEFORE said document is allowed to progress from the
working group to publication. A list of these discussion points will
be documented in the WG document and maintained by the document
editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs specify
as part of the adoption call that the following text describing an
open issue be added to the document in the above-described open
issues section:
  * "Given that the working group has said that it wants to
standardize one data plane solution, and given that the document
contains multiple SRv6 EndPoint behaviors that some WG members
have stated are multiple data plane solutions, the working group
will address whether this is valid and coherent with its one
data plane solution objective.".

Please consider the above guidelines as you decide on whether to support 
or not this WG adoption. Please express clearly your reasoning for 
support/non-support as well as any open discussion points you would like 
addressed should the document be adopted into the working group.


Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring




--
***
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  : stefano.sals...@uniroma2.it
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
***

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Rabadan, Jorge (Nokia - US/Mountain View)]

Hi,

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

Thanks.
Jorge

From: spring  on behalf of James Guichard 

Date: Friday, October 1, 2021 at 4:05 PM
To: SPRING WG 
Cc: spring-cha...@ietf.org 
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/
 as the basis for its compression standardization work. That is part of what 
this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


1.   The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.

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

3.   All open discussion points raised on our mailing list MUST be 
addressed BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.

4.   If this document is adopted by the working group, the chairs specify 
as part of the adoption call that the following text describing an open issue 
be added to the document in the above-described open issues section:

· "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Ahmed Bashandy]

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

Juniper Business Use Only

*From:* spring  *On Behalf Of *Ahmed Bashandy
*Sent:* Tuesday, October 5, 2021 10:53 PM
*To:* James Guichard ; SPRING WG 


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


*[External Email. Be cautious of content]*

I support the adoption of this document.

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

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 15^th 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:

 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:

 1. "Given that the working group has said that it wants to
standardize one data plane solution, and given that the
document contains multiple SRv6 EndPoint behaviors that
some WG members have stated are multiple data plane
solutions, the working group will address whether this is
valid and coherent with its one data plane solution
objective.".

Please consider the above guidelines as you decide on whether to
support or not this WG adoption. Please express clearly your
reasoning for support/non-support as well as any open discussion
points you would like addressed should the document be adopted
into the working group.

Thanks!

Jim, Bruno & Joel

___

spring mailing list

spring@ietf.org  <mailto:spring@ietf.org>

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

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Greg Mirsky]

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) 
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  on behalf of Greg Mirsky <
> gregimir...@gmail.com>
> *Date: *Tuesday, 5 October 2021 at 23:37
> *To: *Robert Raszuk 
> *Cc: *Ron Bonica , James Guichard <
> james.n.guich...@futurewei.com>, SPRING WG ,
> spring-cha...@ietf.org 
> *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  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.
>
>
>
> 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

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

[Ron Bonica]

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  On Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard ; SPRING WG 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]


I support the adoption of this document.

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

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:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel




___

spring mailing list

spring@ietf.org<mailto:spring@ietf.org>

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

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

[Francois Clad (fclad)]

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  on behalf of Greg Mirsky 

Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk 
Cc: Ron Bonica , James Guichard 
, SPRING WG , 
spring-cha...@ietf.org 
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 
mailto:rob...@raszuk.net>> 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.

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 
mailto:40juniper@dmarc.ietf.org>> 
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
___
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Shraddha Hegde]

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  On Behalf Of Ron Bonica
Sent: Friday, October 1, 2021 11:37 PM
To: James Guichard ; SPRING WG 
Cc: spring-cha...@ietf.org
Subject: Re: [spring] WG Adoption call for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

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 mailto:spring-boun...@ietf.org>> On 
Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 AM
To: SPRING WG mailto:spring@ietf.org>>
Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>
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 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://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:


  1.  The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.
  2.  The document is a "living" document; it may change as it goes through 
review and analysis by the SPRING working group.
  3.  All open discussion points raised on our mailing list MUST be addressed 
BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.
  4.  If this document is adopted by the working group, the chairs specify as 
part of the adoption call that the following text describing an open issue be 
added to the document in the above-described open issues section:

 *   "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Antonio Cianfrani]

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)  ha scritto:

> 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"  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.
>
>
>
> The apparent inclination of the working group is to use
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> as the basis for its compression standardization work. That is part of what
> this email attempts to confirm.
>
>
>
> Because of the above the chairs would like to issue a 2-week WG call for
> adoption ending October 15th for
> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
> but with some clear guidelines as follows. By expressing support for
> adoption of this document you are fully aware of and are acknowledging
> that:
>
>
>
> 1.   The SPRING working group is adopting a document that has
> multiple SRv6 Endpoint behaviors.
>
> 2.   The document is a “living” document; it may change as it goes
> through review and analysis by the SPRING working group.
>
> 3.   All open discussion points raised on our mailing list MUST be
> addressed BEFORE said document is allowed to progress from the working
> group to publication. A list of these discussion points will be documented
> in the WG document and maintained by the document editor in conjunction
> with the chairs.
>
> 4.   If this document is adopted by the working group, the chairs
> specify as part of the adoption call that the following text describing an
> open issue be added to the document in the above-described open issues
> section:
>
> · "Given that the working group has said that it wants to
> standardize one data plane solution, and given that the document contains
> multiple SRv6 EndPoint behaviors that some WG members have stated are
> multiple data plane solutions, the working group will address whether this
> is valid and coherent with its one data plane solution objective.".
>
>
>
> Please consider the above guidelines as you decide on whether to support
> or not this WG adoption. Please express clearly your reasoning for
> support/non-support as well as any open discussion points you would like
> addressed should the document be adopted into the working group.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>

-- 

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*

___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Darren Dukes (ddukes)]

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

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

Because of the above the chairs would like to issue a 2-week WG call for 
adoption ending October 15th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
 but with some clear guidelines as follows. By expressing support for adoption 
of this document you are fully aware of and are acknowledging that:


1.   The SPRING working group is adopting a document that has multiple SRv6 
Endpoint behaviors.

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

3.   All open discussion points raised on our mailing list MUST be 
addressed BEFORE said document is allowed to progress from the working group to 
publication. A list of these discussion points will be documented in the WG 
document and maintained by the document editor in conjunction with the chairs.

4.   If this document is adopted by the working group, the chairs specify 
as part of the adoption call that the following text describing an open issue 
be added to the document in the above-described open issues section:

· "Given that the working group has said that it wants to standardize 
one data plane solution, and given that the document contains multiple SRv6 
EndPoint behaviors that some WG members have stated are multiple data plane 
solutions, the working group will address whether this is valid and coherent 
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not 
this WG adoption. Please express clearly your reasoning for support/non-support 
as well as any open discussion points you would like addressed should the 
document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Darren Dukes (ddukes)]

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

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 
mailto:40juniper@dmarc.ietf.org>> 
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
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Ahmed Bashandy]

I support the adoption of this document.

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


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 15^th for 
https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 
 
but with some clear guidelines as follows. By expressing support for 
adoption of this document you are fully aware of and are acknowledging 
that:


 1. The SPRING working group is adopting a document that has multiple
SRv6 Endpoint behaviors.
 2. The document is a “living” document; it may change as it goes
through review and analysis by the SPRING working group.
 3. All open discussion points raised on our mailing list MUST be
addressed BEFORE said document is allowed to progress from the
working group to publication. A list of these discussion points
will be documented in the WG document and maintained by the
document editor in conjunction with the chairs.
 4. If this document is adopted by the working group, the chairs
specify as part of the adoption call that the following text
describing an open issue be added to the document in the
above-described open issues section:
  * "Given that the working group has said that it wants to
standardize one data plane solution, and given that the
document contains multiple SRv6 EndPoint behaviors that some
WG members have stated are multiple data plane solutions, the
working group will address whether this is valid and coherent
with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to 
support or not this WG adoption. Please express clearly your reasoning 
for support/non-support as well as any open discussion points you 
would like addressed should the document be adopted into the working 
group.


Thanks!

Jim, Bruno & Joel


___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

[Greg Mirsky]

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

> 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  wrote:
>
>> "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  wrote:
>>
>>> 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 
>>> wrote:
>>>
 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  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 ?
>
> On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky 
> 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
>>
>> On Tue, Oct 5, 2021, 14:41 Robert Raszuk  wrote:
>>
>>> 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 
>>> wrote:
>>>
 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 
 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.
>
> Well please notice that the draft in question in its introduction
> states:
>
> Abstract
>
>This document 

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

[Robert Raszuk]

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

> "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  wrote:
>
>> 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 
>> wrote:
>>
>>> 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  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 ?

 On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky 
 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
>
> On Tue, Oct 5, 2021, 14:41 Robert Raszuk  wrote:
>
>> 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 
>> wrote:
>>
>>> 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 
>>> 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.

 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