Subject: Re: [spring] Volunteers for the SPRING SRv6 Compression draft
In case my reply here confused folks, more reviewers is better. This reply was
not intended to cut off offers from folks.
Thank you,
Joel
On 9/6/2023 12:23 PM, Joel Halpern wrote:
> Thank you Linda. That would be very help
g On Behalf Of Joel Halpern
Sent: Wednesday, September 6, 2023 11:11 AM
To: SPRING WG List
Subject: [spring] Volunteers for the SPRING SRv6 Compression draft
While we await further discussion between commentors and editors (and
the WG as a whole) on draft-ietf-spring-srv6-srh-compression, I am
lo
drian
-Original Message-
From: spring On Behalf Of Joel Halpern
Sent: 06 September 2023 17:11
To: SPRING WG List
Subject: [spring] Volunteers for the SPRING SRv6 Compression draft
While we await further discussion between commentors and editors (and
the WG as a whole) on draft-ietf-spring-
been involved in implementation nor reading the draft
repeatedly.
Linda
-Original Message-
From: spring On Behalf Of Joel Halpern
Sent: Wednesday, September 6, 2023 11:11 AM
To: SPRING WG List
Subject: [spring] Volunteers for the SPRING SRv6 Compression draft
While we await further discu
: SPRING WG List
Subject: [spring] Volunteers for the SPRING SRv6 Compression draft
While we await further discussion between commentors and editors (and the WG as
a whole) on draft-ietf-spring-srv6-srh-compression, I am looking for at least
two volunteers (more are welcome).
One volunteer is for a
While we await further discussion between commentors and editors (and
the WG as a whole) on draft-ietf-spring-srv6-srh-compression, I am
looking for at least two volunteers (more are welcome).
One volunteer is for a slightly unusual ask. I am looking for someone
who is interested in SRv6 and
I really appreciate the good achievement done by the DT members.
I also prefer to pick up a single solution. Based on SRCOMP presentation, only
CSID can meet all requirements and already there is open source code supporting
CSID. Hence, I think it is ready for WG to proceed with the adoption of
Hi Tony,
If silicon sooner or later get's tailored for SRv6, can't it be made to simply
parse big enough headers?
My understanding of SRv6 is that the SID list is effectively unbounded. It’s
hard to grow silicon to keep up with unbounded. :-)
true, but also true for any factor x by which y
Hi Martin,
> well said.
Thanks.
> With this in mind I'd rather ask: Do we really need SID list compression at
> all?
A very fair question.
> If silicon sooner or later get's tailored for SRv6, can't it be made to
> simply parse big enough headers?
My understanding of SRv6 is that the
Hi Tony,
well said.
With this in mind I'd rather ask: Do we really need SID list compression
at all?
If silicon sooner or later get's tailored for SRv6, can't it be made to
simply parse big enough headers?
IMHO SRv6 is the one thing that really allows for full flexibility for
whatever use
: Vasilenko Eduard
Cc: spring@ietf.org; li_zhenqi...@hotmail.com; Andrew Alston
Subject: Re: [spring] SRv6 compression
[External Email. Be cautious of content]
Hi all,
I have a bit of a different perspective.
Whatever solution is selected, it will be basically forever. Vendors will cut
this
Hi Robert,
> I beg to differ on the "forever" part. Which forwarding technology well maybe
> other then IPv6 is lasting forever. Take ATM, take FR, take even MPLS.
How about IPv4?
It’s very true that link layers can fall out of popularity. Yet the hardware
lives on. I have hardware that f
Hi Tony,
I beg to differ on the "forever" part. Which forwarding technology well
maybe other then IPv6 is lasting forever. Take ATM, take FR, take even
MPLS.
It seems that whatever is most widely deployed and supported today is good
choice for squeezing just a bit more SRv6 header. CSID seems the
Date: Friday, July 30, 2021 at 7:24 AM
To: Gyan Mishra
Cc: "Rabadan, Jorge (Nokia - US/Mountain View)" ,
"Aissaoui, Mustapha (Nokia - CA/Ottawa)" ,
"spring@ietf.org" , Wim Henderickx
Subject: [EXT]Re: [spring] SRv6 compression
Agree.
The DT has do
Hi all,
I have a bit of a different perspective.
Whatever solution is selected, it will be basically forever. Vendors will cut
this into silicon. Quite literally set in stone. It will get deployed and there
will be no turning back.
We should pick the best possible solution because we will have
, Jorge (Nokia - US/Mountain View)" ,
> "Aissaoui, Mustapha (Nokia - CA/Ottawa)" ,
> "spring@ietf.org" , Wim Henderickx
> *Subject: *[EXT]Re: [spring] SRv6 compression
>
> Agree.
> The DT has done a great job in the analysis.
>
> Mov
Many thanks to the DT for the good and thorough work(1)!
And many thanks to Wim for bringing this thread to the list.
My view as an operator is:
We already have more than enough standards and options. Often enough
actually introducing new technology in a multi-vendor environment is a
pain beca
/Antwerp) ; spring@ietf.org
Subject: Re: [spring] SRv6 compression
From my side,
With or without the IETF – I will continue to use CRH and we will continue to
make product choices based on it. CRH is not SRv6 – it is, and we have stated
this before, a building block for many things.
In our case
where it currently resides, to
cater for disparate use cases.
Thanks
Andrew
From: spring On Behalf Of Qiuyuanxiang
Sent: Monday, August 2, 2021 1:01 PM
To: li_zhenqi...@hotmail.com; Henderickx, Wim (Nokia - BE/Antwerp)
; spring@ietf.org
Subject: Re: [spring] SRv6 compression
Agree.
As a
发件人: spring [mailto:spring-boun...@ietf.org] 代表 li_zhenqi...@hotmail.com
发送时间: 2021年7月31日 16:38
收件人: Henderickx, Wim (Nokia - BE/Antwerp); spring@ietf.org
主题: Re: [spring] SRv6 compression
Agree. Picking 1 solution to satisfy our requirements will benefit both the
vendors and the operators.
Best Re
I really appreciate the hard work accomplished by the DT members.
As a user and implementer, I would also agree that it's preferred to pick a
single solution so we can focus the effort to improve and standardize the
selected solution.
Thanks,
--
Kentaro Ebisawa | Mailing List: | Work:
On
...@hotmail.com
发送时间: 2021年7月31日 16:38
收件人: Henderickx, Wim (Nokia - BE/Antwerp) ;
spring@ietf.org
主题: Re: [spring] SRv6 compression
Agree. Picking 1 solution to satisfy our requirements will benefit both the
vendors and the operators.
Best Regards,
Zhenqiang Li
uot; , Wim Henderickx
Subject: [EXT]Re: [spring] SRv6 compression
Agree.
The DT has done a great job in the analysis.
Moving forward with a single, standards track solution is preferred/required
for interoperable SRv6 implementations.
cheers,
Eduard
On Tue, Jul 27, 2021 at 6:09 PM Gyan Mishra
finalizing it and get vendors hardware implementations
>> updated.
>>
>>
>>
>> Regards,
>>
>> Mustapha.
>>
>>
>>
>> *From:* spring *On Behalf Of *Rabadan, Jorge
>> (Nokia - US/Mountain View)
>> *Sent:* Tuesday, July 27, 2021 4:54 A
: spring On Behalf Of Gyan Mishra
Sent: Tuesday, July 27, 2021 6:09 PM
To: Aissaoui, Mustapha (Nokia - CA/Ottawa)
Cc: Rabadan, Jorge (Nokia - US/Mountain View) ;
spring@ietf.org; Henderickx, Wim (Nokia - BE/Antwerp)
Subject: Re: [spring] SRv6 compression
For all operators around the world looking at
BE/Antwerp)
收件人：spring@ietf.org;
日 期 ：2021年07月27日 15:11
主 题 ：[spring] SRv6 compression
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
Given the design team accomplished the work on providing requirements and
a
>
> Mustapha.
>
>
>
> *From:* spring *On Behalf Of *Rabadan, Jorge
> (Nokia - US/Mountain View)
> *Sent:* Tuesday, July 27, 2021 4:54 AM
> *To:* Henderickx, Wim (Nokia - BE/Antwerp) ;
> spring@ietf.org
> *Subject:* Re: [spring] SRv6 compression
>
>
>
>
+1. 😊
Regards,
Keyur
From: spring on behalf of "Henderickx, Wim (Nokia -
BE/Antwerp)"
Date: Tuesday, July 27, 2021 at 12:11 AM
To: "spring@ietf.org"
Subject: [spring] SRv6 compression
Given the design team accomplished the work on providing requirements and
analysis
Matthew
From: spring on behalf of "Aissaoui, Mustapha (Nokia
- CA/Ottawa)"
Date: Tuesday, 27 July 2021 at 15:12
To: "Rabadan, Jorge (Nokia - US/Mountain View)" ,
"Henderickx, Wim (Nokia - BE/Antwerp)" ,
"spring@ietf.org"
Subject: Re: [spring] SRv6
, Wim (Nokia - BE/Antwerp) ;
spring@ietf.org
Subject: Re: [spring] SRv6 compression
I agree with Wim's statement that the precedent in NVO3 *could* apply here too:
pick one solution as Standard's track RFC, and once it is done, the others
might be documented as Informational RFCs if
/Antwerp)
> *Date: *Tuesday, July 27, 2021 at 9:11 AM
> *To: *spring@ietf.org
> *Subject: *[spring] SRv6 compression
>
> Given the design team accomplished the work on providing requirements and
> analysis to compress an SRv6 SID list, I would recommend we pick 1
> solution similar
- BE/Antwerp) ; spring@ietf.org
Subject: Re: [spring] SRv6 compression
Hello,
Knowing the importance of compressed SID for SRv6, it is imperative for the
industry to have a single standardized solution. In this context, it would be
wise for the IETF to leverage on what has been previously
the GENEVE solution.
Many Thanks,
-- Brd
From: spring On Behalf Of Rabadan, Jorge (Nokia -
US/Mountain View)
Sent: Tuesday, July 27, 2021 10:54 AM
To: Henderickx, Wim (Nokia - BE/Antwerp) ;
spring@ietf.org
Subject: Re: [spring] SRv6 compression
I agree with Wim's statement that the prec
: spring on behalf of Henderickx, Wim (Nokia -
BE/Antwerp)
Date: Tuesday, July 27, 2021 at 9:11 AM
To: spring@ietf.org
Subject: [spring] SRv6 compression
Given the design team accomplished the work on providing requirements and
analysis to compress an SRv6 SID list, I would recommend we pick 1
Given the design team accomplished the work on providing requirements and
analysis to compress an SRv6 SID list, I would recommend we pick 1 solution
similar to what was done in NVO3 (when we discussed GENEVE, GUE, GPE, etc)
given this has to be implemented in HW..
I hope we can conclude on thi
> On 26 Jul 2021, at 21:19, Chengli (Cheng Li) wrote:
>
> For sure, our goal is not to deprecate SRv6 but solving the overhead issue of
> SRv6 so that we can use it better.
RFC 8663 gives compact packets over an IPv6 network.
- Stewart___
spring ma
> On 26 Jul 2021, at 20:56, Tony Li wrote:
>
> As I noted within the WG meeting, my preference is that we deprecate SRv6.
+1
It is getting out of hand, and is not a good transport network solution.
Stewart
___
spring mailing list
spring@ietf.org
Hi,
The chairs ask that we opine on the mailing list, so I’m happy to kick things
off.
As I noted within the WG meeting, my preference is that we deprecate SRv6.
Compressing it then becomes moot and there is no issue.
Failing that, the WG needs to come to rough consensus on one mechanism. Th
38 matches
Mail list logo
