Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

If it helps in clarifying updating the definitions may be in order. Anyway it seems more logical that an (IP) interface is defined by its address than the other way around. But I do not know the original intention of the text. I'm not sure I understand your point regarding many functions on many n

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

? By contrast, a Compressed SID Container (i.e., the 128-bit entity that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes But CSID is not an IP address, right? Why IP address rules should be

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

+1 srihari… On 06/10/21, 12:26 AM spring on behalf of Ron Bonica from spring-boun...@ietf.org on behalf of rbonica=40juniper@dmarc.ietf.org said > [External Email. Be cautious of content] Jim, The call for ado

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

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 make

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

+1 to Ron’s comments Julian On 06/10/21, 12:26 AM spring on behalf of Ron Bonica from mailto:spring-boun...@ietf.org on behalf of mailto:rbonica=40juniper@dmarc.ietf.org said > [External Email. Be cautious of content] Jim, The call for adoption has already been posted. There is no way t

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

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 f

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

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 te

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

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

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On Fri, Oct 8, 2021 at 1:38 AM Vasilenko Eduard wrote: > > Ø By contrast, a Compressed SID Container (i.e., the 128-bit entity that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes > > > > But

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

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 J

Re: [spring] 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

[spring] FW: IPR declaration for draft-ietf-spring-mpls-path-segment

From: Greg Mirsky Sent: Friday, October 8, 2021 5:47 PM To: James Guichard Cc: liu.ai...@zte.com.cn; royi.zig...@broadcom.com; spring-cha...@ietf.org; draft-ietf-spring-mpls-path-segm...@ietf.org Subject: Re: IPR declaration for draft-ietf-spring-mpls-path-segment Dear All, I am not aware of

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

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 adopti

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

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

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

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

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

Hi Dear WG， I support the adoption of this draft. Both next and replace flavors are consistent with the SRv6 network programming(RFC 8986)and uses SRH based data plane(RFC 8754), therefore I don't consider these two flavors are two solutions but flexibilities for different scenarios.

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

Hi Tom, It is not related to CSID. Because it is not important how IP address is prepared, it should be IP address at the time of writing to DA field. And it is. You are asking more general question: what was the legal reason to treat IPv6 address as LOC:FUNCT:ARG? Sorry, but it is a little bit

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

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

Re: [spring] 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. 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 responsib

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

Hi Gyan, It is possible to combine SIDs of different C-SID flavors and C-SID lengths in the same SRH, along with those defined in RFC 8986 After all, they leverage the same SRv6 data plane. Let me give you an example. Assume that an SR source node wants to send a packet onto an SR path through

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

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/ [Exter

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

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

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

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

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:

Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02

On 09-Oct-21 06:03, Vasilenko Eduard wrote: > Hi Tom, > > It is not related to CSID. Because it is not important how IP address is > prepared, it should be IP address at the time of writing to DA field. And it > is. > >   > > You are asking more general question: what was the legal reason to t

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

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