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

From: "Voyer, Daniel" <[email-masked]>
Date: Tue, 10 Sep 2019 14:02:10 +0000

Ron,

That was my point in the email thread “Regaining Focus on SRv6 and SRv6+”;

  1.  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
  2.  ISIS/SRv6 is out there since 2015 with lots of iterations

After all these years, why starting something new now and not finish first what is already started ? If there is more needs/requirements, why wasn’t it raised while we were riding on SRH 2014-2019+, and net png ?

Maybe as an IETFer/Vendor “real deployment” doesn’t seem to impress you, but it allows to cycle back and tweak, optimize and enhance 5 years of work (ex.: uSID which is a building block of the overall SRv6 architecture. If we can finish what we started, then we can start something new – such as your proposal.

dan

From: spring <[email-masked]> on behalf of Ron Bonica <rbonica=[email-masked]>
Date: Tuesday, September 10, 2019 at 9:30 AM
To: James Guichard <[email-masked]>, Sander Steffann <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>
Cc: Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>, Shraddha Hegde <[email-masked]>, Andrew Alston <[email-masked]>
Subject: [EXT]Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Jim,

Please accept this comment in the spirit which it is intended, between two old friends.

It doesn’t matter if there are a million existing SRv6 deployments. The following is undeniable:

  *   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
  *   Some customers have identified a need that SRv6+ satisfies and SRv6 does not

So, why would anyone want to suppress the new work. I have heard the following arguments:

  1.  New work would overtax the WG
  2.  A new solution would confuse the market place

The first argument is dubious. We are talking about a few very short documents that are careful never to stray from IPv6 orthodoxy. As always, participation is voluntary.

The second argument is downright suspicious. Network operators are intelligent people who are not easily confused.

The marketplace doesn’t need to be protected from new solutions. Those who claim that it does may want to explain why.

                                                                         Ron

Juniper Business Use Only
From: James Guichard <[email-masked]>
Sent: Tuesday, September 10, 2019 8:59 AM
To: Sander Steffann <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Cc: Rob Shakir <[email-masked]>; Ron Bonica <[email-masked]>; SPRING WG List <[email-masked]>; Shraddha Hegde <[email-masked]>; Andrew Alston <[email-masked]>
Subject: 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 numerous email threads there are several operators stating that SRv6 satisfies their needs (and this is based on real deployment knowledge not theoretical technical purity) and no other additional encapsulation technique is necessary.

My .2c

Jim

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Sander Steffann
Sent: Saturday, September 07, 2019 1:22 PM
To: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Cc: Rob Shakir <[email-masked]<mailto:[email-masked]>>; Ron Bonica <[email-masked]<mailto:[email-masked]>>; SPRING WG List <[email-masked]<mailto:[email-masked]>>; Shraddha Hegde <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>
Subject: 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<https://urldefense.com/v3/__https:/nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-matsushima-spring-srv6-deployment-status-01*23section-3&data=02*7C01*7Cjames.n.guichard*40futurewei.com*7C87bab78edf0e4c4d22d108d733b7f0b8*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637034737431602731&sdata=rfo13CsN3LjWzPWDzGUE48kvRjrnXEbzIHc7obLm144*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUl!8WoA6RjC81c!Up-MQ72jYBIy0LIFVE2tWj_0zcRvGuDpgNHRAGB4ndHJNrus8njuNkSZtEwCiYcm$>. It provides some details on the Significant industry collaboration that led to SRv6 standardization. SRv6 standardization went through the rigorous IETF process (some may say much more rigorous than typically done at IETF).

Throwing massive resources at something, sending many emails and creating many tickets don't represent "significant industry collaboration". They can equally represent ratholing, endless discussions and massive disagreement.

Stop trying to make yourself look superior. That has no place in the IETF. Statement like that are pathetic in my view. Please focus on technical excellence instead.

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Sep 2019 16:29:18 +0200

Hi,

> 	• 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 years, why starting something new now and not finish first what is already started ?

Because many problems are identified in the current work, and I realised I don't like what I see.

> If there is more needs/requirements, why wasn’t it raised while we were riding on SRH 2014-2019+, and net png ?

It's not needs/requirements, it's mostly the lack of a KISS approach

> Maybe as an IETFer/Vendor

I'm an operator

> “real deployment” doesn’t seem to impress you,

Please elaborate about the real deployment. Where was it deployed? In what kind of networks? On what scale? For which use cases?

> but it allows to cycle back and tweak, optimize and enhance 5 years of work (ex.: uSID which is a building block of the overall SRv6 architecture.

I agree. But after 5 years of (re)engineering) it's time to step back and look at the solution again with fresh eyes. https://hackernoon.com/delete-your-code-c5d2dc59f1ff

> If we can finish what we started, then we can start something new – such as your proposal.

I don't like the design of the current solution, and you seem to suggest that I have to stall work on what I would like until you have what you would like *. That doesn't work for me.

Cheers,
Sander

*: Especially with the current attitude/language in the drafts that seems to promote the current work as the only true solution, and everything else as secondary. That might not be the intention, but that is how it appears.

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 10 Sep 2019 23:37:48 +0900

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 <[email-masked]>のメール:

> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Sep 2019 16:41:56 +0200

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.

Not all vendors are falling into the last "S" category

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

I don't like the design of the current solution, and you seem to suggest
> that I have to stall work on what I would like until you have what you
> would like *. That doesn't work for me.

No one is stating that. It is your network and you can deploy and develop
anything you like.

But IETF mission is to make sure you have interoperable services and so far
for all SRv6+ related draft this is all single vendor. Sorry but linux code
does not count.

So do you think that IETF should support and work on single vendor's wall
garden now ? Very interesting ....

I think Juniper reps are actually taking a very risky path ... In fact if
IETF would accept the work - even as experimental - they can only deploy it
in single Juniper shops. So those customers with dual or multi vendor will
have no choice but get rid of Juniper gear.

Cheers,
R.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Sep 2019 17:35:05 +0200

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 little as possible), L3VPN, mVPN (mostly for streaming media distribution). Nothing fancy. I'd love to use SR with plain IPv6 as one step towards the ultimate goal of running the network as simply as possible (i.e. just IPv6) while still having the possibility to steer traffic with as little complications as possible, keeping it easy to learn, easy to understand by NOC engineers, easy to debug and easy to adjust. KISS.

Cheers,
Sander

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Sep 2019 17:48:36 +0200

Hi Robert,

> Please kindly enumerate technical problems which got identified. It will be actually very helpful list.
> 

You clearly don't understand the concept of KISS and prefer to call people stupid because of that… Pathetic.

> No one is stating that. It is your network and you can deploy and develop anything you like.
> 
> But IETF mission is to make sure you have interoperable services and so far for all SRv6+ related draft this is all single vendor. Sorry but linux code does not count.

And Cisco is doing exactly the same. I'm just happy that finally someone is standing up to Cisco in this. I *know* the SRv6+ people have suggested working on interop. Cisco is the one who refused! So don't come to me with this "IETF mission is to make sure you have interoperable services" BS.

> So do you think that IETF should support and work on single vendor's wall garden now ? Very interesting ....

No. And that is why I want SRv6+ to move forward, to avoid getting trapped in the SRv6 walled garden.

> I think Juniper reps are actually taking a very risky path ... In fact if IETF would accept the work - even as experimental - they can only deploy it in single Juniper shops. So those customers with dual or multi vendor will have no choice but get rid of Juniper gear.

I don't care which vendor is behind which proposal. I don't want to get trapped into one vendor's way of thinking. Especially if I don't like that way of thinking. I want to have choice. If SRv6+ is successful it will be implemented by many vendors. A lot of them are still on the fence whether to support SRv6, SRv6+ or both. Let the operators decide what we like best, instead of manipulating the IETF to push a single solution down our throats.

Cheers,
Sander

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Sep 2019 18:09:57 +0200

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 - you contribute to it to either fix it or to
make sure the WG product is the best possible.

So nothing prevented you for all the years IETF has been dealing with SRv6
process to take an active part in its standardization.

Asking for adoption of solution which brings nothing new to already
shipping solution of SR-MPLS when it would travel over IPv4 or IPv6 is at
best counterproductive.

It is like now you would be asking to adopt some individual drafts which
woke up and defined new data plane and new control plane for services you
are running in your network - and call those MPLS+, L2VPN+, L3VPN+ and
mVPN+ without any new functionality.

Would it make sense ?

Kind regards,
Robert

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Sep 2019 18:21:10 +0200

Hi,

> 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 - you contribute to it to either fix it or to make sure the WG product is the best possible.
> 
> So nothing prevented you for all the years IETF has been dealing with SRv6 process to take an active part in its standardization.
> 
> Asking for adoption of solution which brings nothing new to already shipping solution of SR-MPLS when it would travel over IPv4 or IPv6 is at best counterproductive.

No, something that today can do the same as SR-MPLS but over IPv6, with lots of space for future expansion, is something I like to see. Using IPv6 instead of MPLS already gives the benefit of unifying transport technologies. I'm not waiting for something feature packed with so many knobs and "special" (read: header insertion, bit shifting etc) that it will be much harder to work with.

> It is like now you would be asking to adopt some individual drafts which woke up and defined new data plane and new control plane for services you are running in your network - and call those MPLS+, L2VPN+, L3VPN+ and mVPN+ without any new functionality.

That "without any new functionality" isn't exactly true either…

> Would it make sense ?

If those data plane and control plane drafts provide an easier way to do those things? Most definitely yes.

It's the measuring progress by how many features and "cool" things are added that is a problem here. Progress also include making technology easier to manage, easier to understand, easier to debug, more accessible to average network engineers.

Antoine de Saint Exupéry was right: “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”

Cheers,
Sander

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 10 Sep 2019 17:20:56 +0000

Sander, in-line

On 10/09/2019, 18:21, "spring on behalf of Sander Steffann" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

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.

    

    
    
    Cheers,
    Sander

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Sep 2019 19:33:43 +0200

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 you want to also enable L3VPN you configure it in
pretty much identical way regardless if this is SRv6 or SRv6+.

I know I am not going to convince you, but just for the record it is worh
to note that what get's send on the wire is only the information what you
as the vendor need. The fact that spec has prepared encoding to also be
useful for not only you but other operators does not make the solution
"complex".  Otherwise we will end up with protocol per customer which would
be pretty bad I am afraid.

See many people say BGP is complex ... and it is the same here - BGP is as
complex as you require it to be. You can enable BGP 1/1 with 4 lines of
config. But if you need other address families if you need fancy policy you
have all required tools for that on your keyboard.

- - -

Now point about SRv6+ ... see writing a drafts for it easy, Further even
writing interop draft with SRv6 is also not that complex - day or two and
you submit. But please tell me why any vendor who has been working in open
IETF process on any new service for over 5 years now would have to put a
lot of development resources on the table to develop data plane and control
plane enhancements for essentially subset of functionality at best ?

It is nothing about anyone's good will or not ... it is all about limited
resources. Features and extensions are not added to any vendor based on the
RFC translation engine. It is pretty difficult and painful process. So
without huge market demand behind it I would be highly surprised if any
vendor who committed to SRv6 already would now take real on support for
SRv6+.

Thank you,
R.

On Tue, Sep 10, 2019 at 6:21 PM Sander Steffann <[email-masked]> wrote:

> > 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 - you contribute to it to either fix it or
> to make sure the WG product is the best possible.
> >
> > So nothing prevented you for all the years IETF has been dealing with
> SRv6 process to take an active part in its standardization.
> >
> No, something that today can do the same as SR-MPLS but over IPv6, with
> lots of space for future expansion, is something I like to see. Using IPv6
> instead of MPLS already gives the benefit of unifying transport
> technologies. I'm not waiting for something feature packed with so many
> knobs and "special" (read: header insertion, bit shifting etc) that it will
> be much harder to work with.
>
> It's the measuring progress by how many features and "cool" things are
> added that is a problem here. Progress also include making technology
> easier to manage, easier to understand, easier to debug, more accessible to
> average network engineers.
>
> Antoine de Saint Exupéry was right: “Perfection is achieved, not when
> there is nothing more to add, but when there is nothing left to take away.”
>
> Cheers,
> Sander
>
>

---

From: Sander Steffann <[email-masked]>
Date: Tue, 10 Sep 2019 19:39:52 +0200

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

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 10 Sep 2019 18:07:01 +0000

Sander, in-line

On 10/09/2019, 19:39, "Sander Steffann" <[email-masked]> wrote:

    Hi Wim,

WH> with SRv6+ you have to do the same, btw this is no longer MPLS in the strict sense as with LDP/RSVP, it is a tag to make a fwd decision on. Look at it as 32-bit SID which is signaled in IGP. So you are just running an IGP and if you have services, probably MP-BGP or native BGP. 
I am not sure but some people have perception this is MPLS as per RSVP/LDP but it isn’t. it is a tag that represents a prefix-SID/adjacency SID. Nothing more and nothing less.
    
    Cheers,
    Sander

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 10 Sep 2019 20:36:36 +0200

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 to manage any "MPLS" nor any "tunnels". In fact there
is no tunnels ! It is automatic encapsulation to remote segment node. 100%
seamless just like you swap Dest address in the IPv6 fixed encap header.

The CLI front end can be IDENTICAL to SRv6+, the show commands can show you
32 bit SIDs OSPF & ISIS can show you the mapping, BGP L3VPN label will be
still used for L3VPN demux etc ...

Thx
R.

---

From: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 10 Sep 2019 18:59:33 +0000

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  uses 32bit sids, it no longer relies onl LDP/RSVP.

So the 32bit tag is telling you how to fwd the packet and that’s it. It is even local to the router that advertised it.

On top for customers who deployed MPLS there is even easy migration because all these encapsulation interwork at transport level w/o any interworking at service level.

In my view this is very compelling compared to coming up with something new that does the same thing. My 2 cents.

From: Robert Raszuk <[email-masked]>
Date: Tuesday, 10 September 2019 at 20:36
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[email-masked]>
Cc: Sander Steffann <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, SPRING WG List <[email-masked]>, Andrew Alston <[email-masked]>, James Guichard <[email-masked]>, Shraddha Hegde <[email-masked]>, Rob Shakir <[email-masked]>, "Zafar Ali (zali)" <[email-masked]>, "Voyer, Daniel" <[email-masked]>
Subject: 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 to manage any "MPLS" nor any "tunnels". In fact there is no tunnels ! It is automatic encapsulation to remote segment node. 100% seamless just like you swap Dest address in the IPv6 fixed encap header.

The CLI front end can be IDENTICAL to SRv6+, the show commands can show you 32 bit SIDs OSPF & ISIS can show you the mapping, BGP L3VPN label will be still used for L3VPN demux etc ...

Thx
R.

---

From: Andrew Alston <[email-masked]>
Date: Tue, 10 Sep 2019 22:11:36 +0000

<snip>

> https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01<https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-01>
>

I kinda have my own issues with a draft like the one referenced – since – in my view – within the IETF – we create technical documents – that either document a standard, or an experimental technology/protocol, or document particular use cases and information related to that.

This draft in my view – doesn’t really fit into any of that.  To be entirely blunt, I fail to see why we are adopting documents that are nothing more than marketing spin for a particular protocol or set of protocols.  If a protocol or standard has a use case within operators – then let the operators state their case and bring people towards the standard for solid technical base, rather than creating a document that says “oh look some people are using this”.

Furthermore – Much of the discussion of late has been around the network programming draft – and the insertion of headers – with some limited discussion on the uSID stuff.  Reading this document – I see no reference to either – the document seems to be pretty specific to SRH – which does not even sit within the spring working group – but rather in the 6man working group.  Hence, I find this whole document rather bizarre.

But – that’s just my 2c

Andrew

---

From: James Guichard <[email-masked]>
Date: Tue, 10 Sep 2019 22:15:19 +0000

Hi Sander,

Just one comment below ..

-----Original Message-----
From: Sander Steffann <[email-masked]> 
Sent: Tuesday, September 10, 2019 11:49 AM
To: Robert Raszuk <[email-masked]>
Cc: Voyer, Daniel <[email-masked]>; Ron Bonica <rbonica=[email-masked]>; SPRING WG List <[email-masked]>; Andrew Alston <[email-masked]>; James Guichard <[email-masked]>; Shraddha Hegde <[email-masked]>; Rob Shakir <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Jim> this is not an accurate statement as there are vendors other than Cisco that have a deployable and interoperable implementation of SRv6.

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 11 Sep 2019 11:30:02 +0800

Hi, Robert:

But the concept of SRv6+ is more clear than the SRv6(topology/service instruction separation; different instruction carried in different IPv6 EH).  It conforms to RFC8200 as well, seems will be less resisted within 6man WG.

Will such enhancements accelerate the deployment of SR related technologies in service provider network? Anyway it is called SRv6+ J.

We have our own solutions for the similar scenarios that the SR technologies aims to solve, but will also keep eye on the advance of SR/SRv6/SRv6+ technologies.

Best Regards.

Aijun Wang

China Telecom

发件人: [email-masked] [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2019年9月11日 1:34
收件人: Sander Steffann
抄送: Ron Bonica; SPRING WG List; Andrew Alston; James Guichard; Shraddha Hegde; Rob Shakir; Zafar Ali (zali); Voyer, Daniel
主题: 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 you want to also enable L3VPN you configure it in pretty much identical way regardless if this is SRv6 or SRv6+. 

I know I am not going to convince you, but just for the record it is worh to note that what get's send on the wire is only the information what you as the vendor need. The fact that spec has prepared encoding to also be useful for not only you but other operators does not make the solution "complex".  Otherwise we will end up with protocol per customer which would be pretty bad I am afraid. 

See many people say BGP is complex ... and it is the same here - BGP is as complex as you require it to be. You can enable BGP 1/1 with 4 lines of config. But if you need other address families if you need fancy policy you have all required tools for that on your keyboard. 

- - - 

Now point about SRv6+ ... see writing a drafts for it easy, Further even writing interop draft with SRv6 is also not that complex - day or two and you submit. But please tell me why any vendor who has been working in open IETF process on any new service for over 5 years now would have to put a lot of development resources on the table to develop data plane and control plane enhancements for essentially subset of functionality at best ? 

It is nothing about anyone's good will or not ... it is all about limited resources. Features and extensions are not added to any vendor based on the RFC translation engine. It is pretty difficult and painful process. So without huge market demand behind it I would be highly surprised if any vendor who committed to SRv6 already would now take real on support for SRv6+.

Thank you,

R.

 

 

Hi,

Cheers,
Sander

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 11 Sep 2019 12:45:55 +0900

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 instructions, called "segments". A segment can represent any instruction, topological or service based.”

“3.1.3. SRv6 

 When SR is used over the IPv6 data plane: 

 o A Prefix-SID is an IPv6 address. 
 o An operator MUST explicitly instantiate an SRv6 SID. IPv6 node addresses are not SRv6 SIDs by default.”

> different instruction carried in different IPv6 EH).  It conforms to RFC8200 as well, seems will be less resisted within 6man WG.

SRH conforms RFC8200.

> Will such enhancements accelerate the deployment of SR related technologies in service provider network? Anyway it is called SRv6+ J.

SRH has already accelerated SRv6 deployments. 

Best regards,
—satoru

> See many people say BGP is complex .... and it is the same here - BGP is as complex as you require it to be. You can enable BGP 1/1 with 4 lines of config. But if you need other address families if you need fancy policy you have all required tools for that on your keyboard. 
>  
> - - - 
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Sep 2019 13:35:24 +0930

On Wed, 11 Sep 2019, 13:46 Satoru Matsushima, <[email-masked]>
wrote:

>    Segment Routing (SR) leverages the source routing paradigm.  A node
>    steers a packet through an ordered list of instructions, called
>    "segments".  A segment can represent any instruction, topological or service based.”
>
>
> “3.1.3 <https://tools.ietf.org/html/rfc8402#section-3.1.3>.  SRv6
>
>
> different instruction carried in different IPv6 EH).  It conforms to
> RFC8200 as well, seems will be less resisted within 6man WG.
>
>
> SRH conforms RFC8200.
>

This SPRING WG draft does not.

draft-ietf-spring-srv6-network-programming-01

It is referring to the ID which has not been adopted by 6man, has been
ignoring many of the points brought up about it by 6man, and has
proposed Information status.

draft-voyer-6man-extension-header-insertion-05

I would think that a Standards Track ID/RFC cannot depend on an
Informational ID/RFC for any formal functionality.

>
> Will such enhancements accelerate the deployment of SR related
> technologies in service provider network? Anyway it is called SRv6+ J.
>
>
> We have our own solutions for the similar scenarios that the SR
> technologies aims to solve, but will also keep eye on the advance of
> SR/SRv6/SRv6+ technologies.
>
>
>
> Best Regards.
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *发件人:* [email-masked] [mailto:[email-masked]
> <[email-masked]>] *代表 *Robert Raszuk
> *发送时间:* 2019年9月11日 1:34
> *收件人:* Sander Steffann
> *抄送:* Ron Bonica; SPRING WG List; Andrew Alston; James Guichard; Shraddha
> Hegde; Rob Shakir; Zafar Ali (zali); Voyer, Daniel
> *主题:* 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.
>
>
>
> See many people say BGP is complex .... and it is the same here - BGP is
> as complex as you require it to be. You can enable BGP 1/1 with 4 lines of
> On Tue, Sep 10, 2019 at 6:21 PM Sander Steffann <[email-masked]
> <sander@steffann..nl>> wrote:
>
> Hi,
>

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 11 Sep 2019 13:21:12 +0900

> 
>> On Wed, 11 Sep 2019, 13:46 Satoru Matsushima, <[email-masked]> wrote:
>> Hi Aijun,
>> 
>>>  
>>> 

My point was on SRH. Good to see you have no comment on that.

> It is referring to the ID which has not been adopted by 6man, has been ignoring many of the points brought up about it by 6man, and has proposed Information status.
> 
> 
> I would think that a Standards Track ID/RFC cannot depend on an Informational ID/RFC for any formal functionality.

Fine.
—satoru

---

From: Mark Smith <[email-masked]>
Date: Wed, 11 Sep 2019 14:43:28 +1000

> My point was on SRH. Good to see you have no comment on that.

Packet structures aren't protocol definitions.

>> *抄送:* Ron Bonica; SPRING WG List; Andrew Alston; James Guichard;
>> Shraddha Hegde; Rob Shakir; Zafar Ali (zali); Voyer, Daniel
>> > It is like now you would be asking to adopt some individual drafts
>> which woke up and defined new data plane and new control plane for services
>> you are running in your network - and call those MPLS+, L2VPN+, L3VPN+ and

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 11 Sep 2019 13:48:33 +0900

> 
> On Wed, 11 Sep 2019, 14:21 Satoru Matsushima, <[email-masked]> wrote:
>>> 

Huh?
Interesting. I never thought like that thorough witness on lots of design work and discussion in IETF to define bits-n-bytes over the wire. 
—satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 11 Sep 2019 19:16:58 +0900

> ISP in The Netherlands, between 50k and 100k customers three datacenters, multiple interconnect locations, currently using MPLS for L2VPN (as little as possible), L3VPN, mVPN (mostly for streaming…

Thanks. 

We run networks in Japan nation wide for our customers, 5M+ on fixed broadband, 30M+ on 3G/4G cellular, and enterprise business. Bunch of MPLS boxes are deployed in both access aggregation in all 47 prefectural regions (varied size from dense/sub-urban to rural) and backbone networks.(NOTE: not big compare to US/China). Currently L3VPNs run on top of L2VPNs over MPLS(-TP). After long time investigation and discussions internally/externally, we decided to adopt SRv6 more than two years ago. Now SRv6 networks are being deployed, up and running, as part of 5G roll out in addition to those networks, and plan to migrate existing customers to it.

Cheers,
—satoru

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Sep 2019 10:09:22 -0400

You are technically correct that the SR Architecture document does not 
require the separation of topological behavior from service behavior.

On the other hand, MANY of us have notied, and tried to find solutions 
for, the fact that the overloading of IP addresses for both identity and 
location causes significant problems.  Further overloading the same 
thing with service semantics as well makes this problem worse.  So yes, 
there are plenty of good reasons to be concerned about this overloading.

Yours,
Joel

On 9/10/2019 11:45 PM, Satoru Matsushima wrote:
>> *发件人:[email-masked] <mailto:[email-masked]> 
>> [mailto:[email-masked]] *代表 *Robert Raszuk
>> *发送时间:*2019年9月11日1:34
>> *收件人:*Sander Steffann
>> *抄送:*Ron Bonica; SPRING WG List; Andrew Alston; James Guichard; 
>> *主题:*Re: [spring] Going back to the original question for the Spring 
>> WG (was: Re: Beyond SRv6.)
>>
>> Hi Sander,
>>
>> 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 you want to also enable L3VPN you 
>> configure it in pretty much identical way regardless if this is SRv6 
>> or SRv6+.
>>
>> I know I am not going to convince you, but just for the record it is 
>> worh to note that what get's send on the wire is only the information 
>> what you as the vendor need. The fact that spec has prepared encoding 
>> to also be useful for not only you but other operators does not make 
>> the solution "complex".  Otherwise we will end up with protocol per 
>> customer which would be pretty bad I am afraid.
>>
>> See many people say BGP is complex .... and it is the same here - BGP 
>> is as complex as you require it to be. You can enable BGP 1/1 with 4 
>> lines of config. But if you need other address families if you need 
>> fancy policy you have all required tools for that on your keyboard.
>>
>> - - -
>>
>> Now point about SRv6+ ... see writing a drafts for it easy, Further 
>> even writing interop draft with SRv6 is also not that complex - day or 
>> two and you submit. But please tell me why any vendor who has been 
>> working in open IETF process on any new service for over 5 years now 
>> would have to put a lot of development resources on the table to 
>> develop data plane and control plane enhancements for essentially 
>> subset of functionality at best ?
>>
>> It is nothing about anyone's good will or not ... it is all about 
>> limited resources. Features and extensions are not added to any vendor 
>> based on the RFC translation engine. It is pretty difficult and 
>> painful process. So without huge market demand behind it I would be 
>> highly surprised if any vendor who committed to SRv6 already would now 
>> take real on support for SRv6+.
>>
>> Thank you,
>>
>> R.
>>
>> <mailto:sander@steffann..nl>> wrote:
>>
>>     Hi,
>>
>>     No, something that today can do the same as SR-MPLS but over IPv6,
>>     with lots of space for future expansion, is something I like to
>>     see. Using IPv6 instead of MPLS already gives the benefit of
>>     unifying transport technologies. I'm not waiting for something
>>     feature packed with so many knobs and "special" (read: header
>>     insertion, bit shifting etc) that it will be much harder to work with.
>>
>>     It's the measuring progress by how many features and "cool" things
>>     are added that is a problem here. Progress also include making
>>     technology easier to manage, easier to understand, easier to
>>     debug, more accessible to average network engineers.
>>
>>     Antoine de Saint Exupéry was right: “Perfection is achieved, not
>>     when there is nothing more to add, but when there is nothing left
>>     to take away.”
>>
>>     Cheers,
>>     Sander
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Sep 2019 14:33:12 +0000

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 <[email-masked]>
Sent: Tuesday, September 10, 2019 12:10 PM
To: Sander Steffann <[email-masked]>
Cc: Voyer, Daniel <[email-masked]>; Ron Bonica <[email-masked]>; SPRING WG List <[email-masked]>; Andrew Alston <[email-masked]>; James Guichard <[email-masked]>; Shraddha Hegde <[email-masked]>; Rob Shakir <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Hi Sander,

Would it make sense ?

Kind regards,
Robert

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Sep 2019 14:51:41 +0000

Folks,

Can I ask those who have deployed SRv6 how they address SRHs that contain more than 5 or 6 SIDs?

                                                                                                             Ron