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

Folks, Can I ask those who have deployed SRv6 how they address SRHs that contain more than 5 or 6 SIDs? Ron Juniper Business Use Only ___

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

Robert, Are you suggesting an attempt to merge the best of SRv6 with the best of SRv6+? This might be a good idea. Ron From: Robert Raszuk Sent: Tuesday, September 10, 2019 12:10 PM To: Sander Steffann Cc: Voyer, Daniel ;

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] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Hi Sander, Just one comment below .. -Original Message- From: Sander Steffann Sent: Tuesday, September 10, 2019 11:49 AM To: Robert Raszuk Cc: Voyer, Daniel ; Ron Bonica ; SPRING WG List ; Andrew Alston ; James Guichard ; Shraddha Hegde ; Rob Shakir ; Zafar Ali (zali) Subject:

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

>> Please elaborate about the real deployment. Where was it deployed? In what >> kind of networks? On what scale? For which use cases? > > https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01

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

Robert, thx for confirming and indeed there is a misperception on mpls in ctxt of Segment routing. First we can transport SR-MPLS using MPLS on the wire with v4 or v6 CP and also native IP encapsulation using ipv4-udp or ipv6-udp dataplane. Signaling wise it is based on IGP(s) ISIS/OSPF and

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

Hi Wim, > I am not sure but some people have perception this is MPLS as per RSVP/LDP but it isn’t. Exactly. See: https://mailarchive.ietf.org/arch/msg/spring/qvRUp8SC2cWeIE5UhhU9aKGtpHM > No, I don't want to have to manage both MPLS and tunnels. That only adds complexity. No one would ask you

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

Sander, in-line On 10/09/2019, 19:39, "Sander Steffann" wrote: Hi Wim, > WH> Would you be ok with this? https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07, support segment routing over IPv4 and/or IPv6. No, I don't want to have to manage both MPLS and tunnels.

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

Hi Wim, > WH> Would you be ok with this? > https://tools.ietf.org/html/draft-ietf-mpls-sr-over-ip-07, support segment > routing over IPv4 and/or IPv6. No, I don't want to have to manage both MPLS and tunnels. That only adds complexity. Cheers, Sander signature.asc Description: Message

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

Hi Sander, You keep saying SRv6 is complex. But it is only as complex as you are going to make it or as you will need it to be. No one is mandating you to do any network programming or to use multiple TLVs. If you just need to use SR for basic TE you insert one or two SIDs and you are done. If

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

Sander, in-line On 10/09/2019, 18:21, "spring on behalf of Sander Steffann" wrote: Hi, > No. And that is why I want SRv6+ to move forward, to avoid getting trapped in the SRv6 walled garden. > > The way IETF works (at least in vast majority of WGs) is that if you do

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

Hi, > No. And that is why I want SRv6+ to move forward, to avoid getting trapped in > the SRv6 walled garden. > > The way IETF works (at least in vast majority of WGs) is that if you do not > like a specific element of a solution or if something is missing from any > solution during WG

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

Hi Sander, No. And that is why I want SRv6+ to move forward, to avoid getting trapped > in the SRv6 walled garden. > The way IETF works (at least in vast majority of WGs) is that if you do not like a specific element of a solution or if something is missing from any solution during WG process -

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

Hi Robert, >> Because many problems are identified in the current work > > Please kindly enumerate technical problems which got identified. It will be > actually very helpful list. > >> It's not needs/requirements, it's mostly the lack of a KISS approach > > Not all vendors are falling into

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. ISP in The Netherlands, between 50k and 100k customers three datacenters, multiple interconnect locations, currently using MPLS for L2VPN (as

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

Dear Sander, Because many problems are identified in the current work > Please kindly enumerate technical problems which got identified. It will be actually very helpful list. It's not needs/requirements, it's mostly the lack of a KISS approach > Not all vendors are falling into the last "S"

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

Hi, > That was my point in the email thread “Regaining Focus on SRv6 and SRv6+”; > > • SRH has been around since 5 years with now 22 versions the last call > is done, it’s on its way to become an RFC > • ISIS/SRv6 is out there since 2015 with lots of iterations > > After all these

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] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

I don’t think anyone is trying to make themselves look superior. Presumably the IETF wants to build technologies that are actually deployed in real networks – it is clear that there are multiple publicly announced SRv6 deployments (I can think of at least 5) and from what I can see from the

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

On 7/9/19 20:10, Zafar Ali (zali) wrote: [] > > Rough consensus and running code... But we work by rough consensus. > > Running code that explicitly goes against consensus is no IETF standard > at al. > >   > > [ZA] Please refer to section 3 of SRv6 deployment > draft,  >

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

> [ZA] Please refer to section 3 of SRv6 deployment draft, > https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01#section-3. > It provides some details on the Significant industry collaboration that led > to SRv6 standardization. SRv6 standardization went through the

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

Hi, Please see in-line. Thanks Regards … Zafar From: Sander Steffann Date: Saturday, September 7, 2019 at 12:57 PM To: Andrew Alston Cc: "Zafar Ali (zali)" , Ron Bonica , Shraddha Hegde , Rob Shakir , SPRING WG List Subject: Re: [spring] Going back to the original question for the Spring

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

Hi, I noticed this bit of your message, and it made me think. > With regards to your points about its all already developed – are you really > telling me that because the authors chose to go and spend ages developing > something while taking zero cognizance of the consensus in the community on

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

Zafar, While I am not going to answer all the points in your email – I am going to raise one issue. You talk about NOT debating a solution. I point out that it was also stated in Montreal that we needed an analysis of the IPv6 address space required by the network programming and usid

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

Ron, > There hasn't been a single mail denying the above advantages of SRv6+ Among many comments from many operators and vendors, please see, https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4 We must remind you that the original questions from the Spring chair were