Re: [spring] Working Group Adoption Call for draft-filsfils-spring-segment-routing-policy

I support this adoption. cheers, --satoru > 2018/05/17 0:20、Rob Shakir のメール: > > Hi SPRING WG, > > This email initiates a two week call for working group adoption for > draft-filsfils-spring-segment-routing-policy. Please indicate your support, > or otherwise, for adopting this draft as a

[spring] Please count the SRv6 for Mobile work [was Re: SPRING - rechartering discussion]

Hello SPRING folks, Let me share an ongoing work in DMM WG that makes SRv6 to be able to provide mobility management path on user plane: https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane So please count it when you consider rechartering. But it doesn’t mean that SPRING WG is

Re: [spring] draft-filsfils-spring-srv6-network-programming

Hi Spring, It’s my pleasure that we can finally announce our successful SRv6 deployment. I think that the experience and knowledge from the project contributed to the maturity of SRv6 network programming I-D. I hope that it helps the I-D to be adopted as a WG doc, and it also contributes to

Re: [spring] WG Adoption Call: draft-xuclad-spring-sr-service-programming

Hi, I support this adoption. --satoru > 2019/06/27 15:13、Rob Shakir のメール: > > Hi SPRING WG, > > This email initiates a two week working group adoption call for > draft-xuclad-spring-sr-service-programming. This follows the discussion that > we had in the last few IETF meetings, and

Re: [spring] Beyond SRv6.

Hi, As part of the 5G rollout, Softbank have deployed a nationwide SRv6 network carrying commercial traffic with the linerate performance using Merchant Silicon. https://www.softbank.jp/corp/news/press/sbkk/2019/20190424_03/ # You can read it in your language through some translation service,

Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

> > On Wed, 11 Sep 2019, 14:21 Satoru Matsushima, > wrote: >>> >>>> On Wed, 11 Sep 2019, 13:46 Satoru Matsushima, >>>> wrote: >>>> Hi Aijun, >>>> >>>>> >>>>> >>&

Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

> >> On Wed, 11 Sep 2019, 13:46 Satoru Matsushima, >> wrote: >> Hi Aijun, >> >>> >>> >>> But the concept of SRv6+ is more clear than the SRv6(topology/service >>> instruction separation; >>> >> >> The SR

Re: [spring] 答复: Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Hi Aijun, > > But the concept of SRv6+ is more clear than the SRv6(topology/service > instruction separation; The SR architecture never require such things. See RFC8402: “Abstract Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of

Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Hi, If you say you are an operator, and ask us to disclose on where, for what, scale and use case, please describe yours at first in very detail. thanks, --satoru 2019/09/10 23:29、Sander Steffann のメール: > Hi, > >> That was my point in the email thread “Regaining Focus on SRv6 and SRv6+”; >>

Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Ron, > SRv6 is not nearly so close to standardization as some would claim. If it > were, last week’s heated email exchanges would not have occurred It’s not true. All discussions didn’t attribute to SRH encap itself. > Some customers have identified a need that SRv6+ satisfies and SRv6 does

Re: [spring] Beyond SRv6.

Excellent news. I’d capture your case in the SRv6 deployment draft, in case you’d be okay. Cheers, --satoru 2019/09/11 9:55、Hirofumi Ichihara のメール: > Hi folks, > ​ > Let me mention my opinion as an operator. > ​ > Our company already has deployed and used SRv6 Network in our DC. Our use >

Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

2019/09/11 0:35、Sander Steffann のメール: > Hi, > >> If you say you are an operator, and ask us to disclose on where, for what, >> scale and use case, please describe yours at first in very detail. > > ISP in The Netherlands, between 50k and 100k customers three datacenters, > multiple

Re: [spring] SPRING SRv6 Deployment Status draft

Thanks Shuping, good to hear that new deployment! Yes, will capture it in the next revision too. cheers, --satoru > On Nov 7, 2019, at 11:28, Pengshuping (Peng Shuping) > wrote: > >  > Hi Satoru, Zafar, > > We are announcing another deployment of SRv6. MTN has deployed SRv6, as >

Re: [spring] SPRING SRv6 Deployment Status draft

fts > directories. > > >Title : SRv6 Implementation and Deployment Status >Authors : Satoru Matsushima > Clarence Filsfils > Zafar Ali > Zhenbin Li >File

Re: [spring] IPR poll for draft-ietf-spring-srv6-network-programming

Hi, I’m not aware of any undisclosed IPR related to this draft. Cheers, --satoru > 2019/12/06 1:50、bruno.decra...@orange.comのメール: > > Hi SPRING WG, > > In parallel to the WGLC for draft-ietf-spring-srv6-network-programming, we > would like to poll for IPR. > > If you are aware of IPR that

[spring] Fwd: New Version Notification for draft-matsushima-spring-srv6-deployment-status-04.txt

. Best regards, --satoru > 転送されたメッセージ: > > 差出人: > 件名: New Version Notification for > draft-matsushima-spring-srv6-deployment-status-04.txt > 日付: 2019年12月12日 5:12:51 JST > 宛先: Zafar Ali , Clarence Filsfils , > Zhenbin Li , Satoru Matsushima > > > > A new ver

Re: [spring] draft-ietf-spring-srv6-network-programming: Section 4.16

Joel, > 2019/10/18 1:14、Joel M. Halpern のメール: > > Pretending it is legitimate, let me ask a different aspect of the question. > > Removing bytes (aor adding bytes) from arbitrary positions in the middle of a > packet is generally any extremely painful operation. Why would we want a >

Re: [spring] New Version Notification for draft-matsushima-spring-srv6-deployment-status-02.txt

sed in the draft, there will be >>> more SRv6 for different application scenariosin >>> the near future. These SRv6 deployments are also promoting the IPv6 >>> deployment and more IPv6 traffic will be beared by >>> these networks. >>> >>> >>

Re: [spring] Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming

+1 Cheers, --satoru > 2020/02/27 6:37、Voyer, Daniel のメール: > > +1 > > Thanks > dan > > From: Dirk Steinberg > Date: Wednesday, February 26, 2020 at 12:52 PM > To: "Zafar Ali (zali)" > Cc: Lizhenbin , Bruno Decraene > , SPRING WG List , > "6...@ietf.org" <6...@ietf.org>, "Zafar Ali

Re: [spring] WGLC - draft-ietf-spring-srv6-network-programming

Thank you Martin, I support this clear statement. Even WG/AD management is expected to find the essence from bunch of emails, it shouldn't be easy task. Great job, thanks. Best regards, --satoru > 2020/03/05 6:02、Martin Vigoureux のメール: > > WG, > > I wanted to bring more context to my

Re: [spring] SRv6's new deployment status information at OSS-fields.

Thank you Hiroki, yes it’s a great news indeed! I’d be happy to capture this (and your coming outcomes) in the next revision of srv6-deployment status draft. Cheers, --satoru > On Jan 17, 2020, at 20:16, Hiroki Shirokura wrote: > >  > Dear all SRv6-ers > I'm Hiorki working on developing

Re: [spring] draft-ietf-spring-srv6-network-programming - 2 week Early Allocation Call

Support. 2019年12月20日(金) 1:54 : > Hi SPRING WG, > > > > This begins a 2 week Early Allocation call for a “Ethernet” value from the > "Protocol Numbers" registry. > > https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-07#section-9.1 > >

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03

Support this adoption. Cheers, --satoru > 2020/10/22 21:51、James Guichard のメール: > > Dear WG: > > This message starts a 3 week WG adoption call for > https://tools.ietf.org/html/draft-gandhi-spring-stamp-srpm-03 > , ending >

Re: [spring] WG Adoption Call for https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11

Support this adoption too. Cheers, --satoru > 2020/10/22 21:51、James Guichard のメール: > > Dear WG: > > This message starts a 3 week WG adoption call for document > https://tools.ietf.org/html/draft-gandhi-spring-twamp-srpm-11 >

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

Hi spring chairs, I think that the document is ready to move forward. Here one minor comment is bellow: Section 6.2 says on BSID as follow: When the active candidate path has a specified BSID, the SR Policy uses that BSID if this value (label in MPLS, IPv6 address in SRv6) is

Re: [spring] WGLC for draft-ietf-spring-segment-routing-policy

ient, to another SID, to another SR Policy, outside the range of SRv6 > Locators). > > Thanks, > Ketan > > From: spring On Behalf Of Satoru Matsushima > Sent: 29 April 2021 18:36 > To: spring-cha...@ietf.org > Cc: James Guichard ; spring@ietf.org > Subject: Re: [s

Re: [spring] Progressing Standardizing SR over IPv6 compression

Hi Chairs, and WG, As an SRv6 network operator, I support that the WG adopts one single data plane behavior and standardize it as the SRv6 SID list compression spec. It is simple and IMO the best way for all of us. Cheers, --satoru > On Aug 18, 2021, at 5:28, James Guichard > wrote: > Dear

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

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

Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis

Dear SPRING chairs, after my review of these two document, I support this adoption. Cheers, --satoru > On Sep 7, 2021, at 22:13, bruno.decra...@orange.com wrote: > >  > Dear WG, > > > The Design Team has produced two documents: > - A requirement document:

Re: [spring] Issue 1 regarding draft-ietf-spring-srv6-srh-compression

This issue was resolved and I agree to close issue#1. Best regards, --satoru On Tue, Aug 1, 2023 at 6:08 AM Joel Halpern wrote: > As per the discussions on list and at IETF 117, the SPRING WG chairs > (myself and Alvaro specifically) are attempting to determine if we can > close the open

Re: [spring] Fwd: IETF WG state changed for draft-ietf-spring-srv6-srh-compression

Hi SPRING WG, I support this document to be advanced. It is helpful for various SRv6 deployment cases. Best regards, --satoru On Mon, Jan 22, 2024 at 6:28 AM Joel Halpern wrote: > (One of the other chairs pointed out that this had not gone to the list. > So forwarding the announcement.) > >