Re: [spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming

On Sat, 7 Sep 2019, 15:18 Bernier, Daniel, wrote: > Hi Fernando, > > > > Let’s say I have a native *IPv6 application flow* to which I want to > apply a service policy (i.e. chain of functions), carry metadata through > TLVs or perform a very simplistic filtering action via the tag field. All > of

Re: [spring] Regaining Focus on SRv6 and SRv6+

On Sat, 7 Sep 2019 at 14:58, Huzhibo wrote: > > Hi Robert: > > > > Agree with you. > > SRv6 is a completely different technology from SR MPLS. The biggest > difference is that SRv6's Sid itself has routing capabilities. For example, > it is aggregatable, it is programmable, it is globally unique

Re: [spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming

Hi Fernando, Let’s say I have a native IPv6 application flow to which I want to apply a service policy (i.e. chain of functions), carry metadata through TLVs or perform a very simplistic filtering action via the tag field. All of which are real use cases by the way. Should I not leverage insert

Re: [spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming

< An engineer comes out from the trenches/ > Hi Fernando, I will attempt to answer and but also setup the context first. The context: 1) SRv6 is trying to enhance certain capabilities in IPv6 for specific deployments (2). The idea is to use IPv6 pervasively for various current features in thos

Re: [spring] Regaining Focus on SRv6 and SRv6+

Hi Robert: Agree with you. SRv6 is a completely different technology from SR MPLS. The biggest difference is that SRv6's Sid itself has routing capabilities. For example, it is aggregatable, it is programmable, it is globally unique over a larger scope. of. Sid's routing capabilities bring many

[spring] Question about IPv6 EH-insertion in draft-ietf-spring-srv6-network-programming

Folks, I have one specific question regarding this I-D: What is the motivation for doing EH-insertion, instead of creating a new packet with the necessary EHs, and include the original packet in the payload? Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerp

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

On 6/9/19 06:26, Ron Bonica wrote: > Ole, > > The IETF does not write de jure standards. At the same time, it must not > blithely progress proposals that ignore existing standards. We need to find a > balance. > > Generally speaking, proposals that conform to the spirit and letter of > existin

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

On 7/9/19 04:07, Mark Smith wrote: > > > On Sat, 7 Sep 2019, 09:00 Tom Herbert, > wrote: > > On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk > wrote: > > > > Sander, > > > > But this is exactly what both chairs of 6man

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

On 7/9/19 01:59, Tom Herbert wrote: > On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk wrote: >> >> Sander, >> >> But this is exactly what both chairs of 6man did with the help of AD long >> time back. You must have missed it ! >> >> And below is a link precisely written to address requirement of jus

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Mark, Thanks for saying what we were all thinking. Ron Sent from my phone On Sep 6, 2019, at 9:07 PM, Mark Smith mailto:markzzzsm...@gmail.com>> wrote: On Sat, 7 Sep 2019, 09:00 Tom Herbert, mailto:t...@herbertland.com>> wrote: On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk mailto:rob...@ra

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

On Sat, 7 Sep 2019, 09:00 Tom Herbert, wrote: > On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk wrote: > > > > Sander, > > > > But this is exactly what both chairs of 6man did with the help of AD > long time back. You must have missed it ! > > > > And below is a link precisely written to address re

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

On Fri, Sep 6, 2019 at 3:11 PM Robert Raszuk wrote: > > Sander, > > But this is exactly what both chairs of 6man did with the help of AD long > time back. You must have missed it ! > > And below is a link precisely written to address requirement of justifying > deviation: > > https://tools.ietf.

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

> My problem is that Fernando is being told to defend the existing RFC. And who told him to do that ? Some one who recommended him to grep for "insertion" string in the text without understanding the full sentences where such world may exist ? Hmmm why would anyone do that ? By that notion it wo

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Hi, > What consensus has been reached that you are referring to? The consensus on the text of RFC8200. Cheers, sander ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Spirit and Letter of the Law

Tom Herbert wrote on 06/09/2019 23:26: What consensus has been reached that you are referring to? rfc8200. Nick ___ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

On Fri, Sep 6, 2019 at 3:20 PM Sander Steffann wrote: > > Hi Ole, > > > Proposals are judged on their merits. > > There is no protocol police. > > There is existing consensus, and changing that requires consensus on the > changes. The onus is on those wanting the change, yet you demand the ones

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Hi Robert, > All SRv6 existing specs can progress just fine with that last mode of > insertion being removed if rough consensus in 6man would not get reached. My problem is that Fernando is being told to defend the existing RFC. That is wrong. It is up to the SRv6 proposers to argue and defend

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Hi Ole, > Proposals are judged on their merits. > There is no protocol police. There is existing consensus, and changing that requires consensus on the changes. The onus is on those wanting the change, yet you demand the ones referring to the existing consensus to defend themselves. That is n

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Sander, But this is exactly what both chairs of 6man did with the help of AD long time back. You must have missed it ! And below is a link precisely written to address requirement of justifying deviation: https://tools.ietf.org/html/draft-voyer-6man-extension-header-insertion-06 And let me repe

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

>> I don’t see a need to continue this debate on meta issues, but since you >> framed this as criticism of me in the chair role I found it required to >> reply. > > I expect the chair to uphold a previously reached consensus and put the > requirement of justifying deviating from it with the o

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Hi Ole, > I don’t see a need to continue this debate on meta issues, but since you > framed this as criticism of me in the chair role I found it required to > reply. I expect the chair to uphold a previously reached consensus and put the requirement of justifying deviating from it with the on

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

> > > >> I think you have repeatedly made your point. > > Yes he has, and he makes a good point that should be heard. Your argument of > "RFCs aren't the law, and we can ignore parts of them if it suits us" just > isn't true. RFCs are based on consensus, and ignoring the outcome of that > co

Re: [spring] Spirit and Letter of the Law (was: Question about SRv6 Insert function)

Hi Ole, > I think you have repeatedly made your point. Yes he has, and he makes a good point that should be heard. Your argument of "RFCs aren't the law, and we can ignore parts of them if it suits us" just isn't true. RFCs are based on consensus, and ignoring the outcome of that consensus whe

[spring] IPR Disclosure Cisco's Statement about IPR related to draft-guichard-spring-nsh-sr

Dear Jim Guichard, Haoyu Song, Jeff Tantsura, Joel M. Halpern, Wim Henderickx, Mohamed Boucadair, Syed Hassan: An IPR disclosure that pertains to your Internet-Draft entitled "NSH and Segment Routing Integration for Service Function Chaining (SFC)" (draft-guichard-spring-nsh-sr) was submitted to

Re: [spring] Regaining Focus on SRv6 and SRv6+

I also agree 100% with Robert and Dirk. Alright, has this tread grow, I am getting confused, here’s why: First, is it a fair statement to say that there is no SRv6+ deployment with real experience ? Yes or no, I’m just curious to know. There are some SRv6 deployments – facts: https://tools.iet

Re: [spring] Question about SRv6 Insert function

Robert, So, you don’t want to prevent innovation. Just make it very difficult 😉 Ron From: Robert Raszuk Sent: Friday, September 6, 2019 11:56 AM To: Ron Bonica Cc: Darren Dukes (ddukes) ; Fernando Gont ; spring@ietf.org; 6..

Re: [spring] Question about SRv6 Insert function

I second this - and I was extremely clear in my email to spring a few weeks ago - I believe that there is place for both srv6+ and the alternatives - especially since I point out that srv6+ solves an overhead problem that was not solved by srh or the programming draft - and actually pre-dates th

Re: [spring] Question about SRv6 Insert function

Well the term "*shut* *down"* is not precise here. IETF can not shut any work .. you can keep working on anything you like and keep submitting individual drafts for it. If you are nice to an AD he me even sponsor it for publication. SPRING WG however already has spectrum of mature solutions which

Re: [spring] Question about SRv6 Insert function

Robert, Your comment about killing innovation in the IETF strikes me as being odd. I never recommended shutting down SRv6 work. In fact, I support it. It is you who are asking to shut down SRv6+ work. So, who is looking to kill innovation in the IETF?

Re: [spring] Regaining Focus on SRv6 and SRv6+

Hi Dirk, Agree with the understanding of MPLS over UDP. Also, I don’t think the performance of processing TLVs in DOH will be good, seems very complicated. But I will not say which compression mechanism is better, since there maybe thousands of them, and we should not discuss this topic before

Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Correct, that is what I want to say. Thanks Ketan for your information. I think Ron understands the usage of Binding SID very well, but I am very curious about why he said there is no need to have a binding SID. Cheng Li Email: chengl...@huawei.com

Re: [spring] Regaining Focus on SRv6 and SRv6+

I agree with Robert 100%. If you want to use MPLS with IPv6, fine go ahead and do so. All you need is already there. No need to re-invent MPLS over UDP using a different encapsulation inappropriately named "SRv6+". SRv6 provides many distinct advantages over MPLS but nobody is forced to use it. B

Re: [spring] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

Hi Ron, Binding SID is very useful in inter-domain routing, not only for shortening SID list, but also for security and privacy. So I think Binding SID is a good design for any kind of Source Routing paradigm. The only problem we should discuss is that how to handle it.But I doubt the cost of

Re: [spring] Regaining Focus on SRv6 and SRv6+

Hi Tarek, > OK, but how about traffic engineering (or source routing) in native IPv6 transport? SRv6 or for that matter SRv6+ works on the basis of swapping dst address in the packets. So except segment endpoints all other routers in the domain are basic IPv6 nodes. It is native IPv6 transport.

Re: [spring] Regaining Focus on SRv6 and SRv6+

Please see my elaborated note on that ... https://mailarchive.ietf.org/arch/msg/spring/qvRUp8SC2cWeIE5UhhU9aKGtpHM Cheers, R. On Fri, Sep 6, 2019 at 4:03 PM Tarek Saad wrote: > Hi Robert, > > > > >> * If operators choose not to use MPLS transport SR-MPLS can be easily > transported over IPv4 o

Re: [spring] Beyond SRv6.

I don't think so. In OAM packets are on purpose made huge - even up to MTU to make sure real customer packets can go through or to detect and diagnose MTU issues. So adding SRH to it is nothing one can call inefficient. Wrong tree :) Cheers, R. On Fri, Sep 6, 2019 at 4:14 PM Srihari Sangli wro

Re: [spring] Beyond SRv6.

On Fri, Sep 6, 2019 at 1:40 AM Andrew Alston < andrew.als...@liquidtelecom.com> wrote: > An Zafar – I told by those words – I am pragmatic though as an operator. > I know that srv6 in some form or another is coming – I stated as much on > various blogs. I am not fool enough to believe that I am no

Re: [spring] Regaining Focus on SRv6 and SRv6+

Robert, If I understand your elaborate response, you hint to keeping MPLS as demux for services and native IPv4/IPv6 for transport.. which may not address bunch that religiously don’t want to enable MPLS. OK, but how about traffic engineering (or source routing) in native IPv6 transport? Seems

Re: [spring] Beyond SRv6.

On 06/09/19, 4:32 PM Robert Raszuk from rob...@raszuk.net said > Not really. Only SR OAM packets may need it. Is that a real problem ? Thanks for clarification. Like Ron pointed out before, its inefficient encoding. srihari… ___

Re: [spring] Beyond SRv6.

Hi Zafar, >> In the vast majority of the deployments (single SP domain), one can deploy >> MPLS. >> In a minority of cases where some MPLS discontinuity in the domain could >> exist, SR-MPLS over IP/UDP is an adopted and deployed solution. For an operator who has used MPLS, don’t you think SRv6+

Re: [spring] Regaining Focus on SRv6 and SRv6+

Hi Robert, >> * If operators choose not to use MPLS transport SR-MPLS can be easily >> transported over IPv4 or IPv6 vanilla data plane I’m little confused about the above argument – given it starts with don’t want to use MPLS, can you clarify? Regards, Tarek From: spring on behalf of Robert

Re: [spring] Regaining Focus on SRv6 and SRv6+

Dear Ron, I think you forgot few main points in the summary: * Many operators use SR-MPLS successfully and it has been both standardized and successfully deployed in the network with interoperable implementations * The overhead on the data plane of SRv6+ is very comparable to overhead of SR-MPLS

[spring] Regaining Focus on SRv6 and SRv6+

Folks, We have explored many facets of SRv6 and SRv6, sometime passionately. I think that this exploration is a good thing. In the words of Tolkien, "All who wander are not lost." But it may be time to refocus on the following: * For many operators, SRv6 is not deployable unless the probl

Re: [spring] Beyond SRv6.

> > Vanilla TRACEROUTE reveals all of the mapping information. RFC 5837 offers > some nice extras, but isn't strictly required. > Really ? If your traffic policy steers some TCP traffic for ports 4000-5000 to take segment A-B-C-D and for ports 6000-7000 to take segment A-E-F-G-D how your vanilla

Re: [spring] Beyond SRv6.

Steinar, Vanilla TRACEROUTE reveals all of the mapping information. RFC 5837 offers some nice extras, but isn't strictly required. Ron Juniper Business Use Only -Original Message- From: sth...@nethelp.no S

Re: [spring] Beyond SRv6.

Not really. Only SR OAM packets may need it. Is that a real problem ? Best R On Fri, Sep 6, 2019, 11:41 Srihari Sangli wrote: > Zafar, > > > > · The original segment list is maintained by using the > non-Reduced flavor (in which case the SID list is fully preserved in the > SRH). > > >

Re: [spring] Beyond SRv6.

Zafar, · The original segment list is maintained by using the non-Reduced flavor (in which case the SID list is fully preserved in the SRH). [RB] At the cost of encoding efficiency. 50% decrease !! If I understand it right, the IPv6 packet carrying uSIDs will also have full set SID

Re: [spring] Spirit and Letter of the Law - non-technical side note

Hi Alex, This is really spot on and very brilliant summary of the state we are in ! And since last 25 years rather proved that the first options is not working the choice seems pretty clear that we should rather choose the second one. Best, R. On Fri, Sep 6, 2019 at 10:57 AM Alexandre Petrescu

Re: [spring] Spirit and Letter of the Law - non-technical side note

This is a non-technical side note about the Spirit and Letter of the Law in IPv6 WG. In these discussions about IPv6 like routing header, insertion, mutability, 64bit, limited domains, multihoming, smart end dumb network, and numerous other 'tussles', one is supposed to take a side among one of

Re: [spring] Beyond SRv6.

> between those who want MPLS to die Again you are putting an equal sign between MPLS used for transport and MPLS used for application and services. While I know and agree that MPLS for transport should die - I have not met anyone who says MPLS for applications is a bad demux encoding. > for the

Re: [spring] Beyond SRv6.

An Zafar – I told by those words – I am pragmatic though as an operator. I know that srv6 in some form or another is coming – I stated as much on various blogs. I am not fool enough to believe that I am not going to be forced into a situation where I am going to be made to run some variant of t

Re: [spring] Question about SRv6 Insert function

> what the current drafts do – is fundamentally rewrite the ipv6 protocol I think you are giving small team of focused engineers way too much credit here :) What they tried to do is to merely make sure that if someone decides to use IPv6 they have a chance to not only have functional parity with

Re: [spring] Beyond SRv6.

Hi Andrew, I agree with Robert. CRH is nothing else than IPv6 over SR-MPLS. In the vast majority of the deployments (single SP domain), one can deploy MPLS. In a minority of cases where some MPLS discontinuity in the domain could exist, SR-MPLS over IP/UDP is an adopted and deployed solution. As

Re: [spring] Question about SRv6 Insert function

Robert, my problem here is – I believe that there could have been common ground found between various proposals except – what the current drafts do – is fundamentally rewrite the ipv6 protocol – the changes in the address semantics (twice over in incompatible ways between the programming draft a

Re: [spring] Question about SRv6 Insert function

Ron, > They remind us that draft-ietf-spring-network-programming are far from maturity. To me it actually highlights something quite contrary. It is that some folks are pretty far from appreciating or even grasping the value of the proposal. In your other note you have extensively elaborated wel

Re: [spring] Beyond SRv6.

Hi Andrew, I can say that I may even agree with some of your points. But one question I asked which no one responded still stands ... SRv6+ is almost identical to SR-MPLS with IP transport between segment nodes. Both require mapping, both require changes to OAM, both require IGP extensions, both

Re: [spring] Beyond SRv6.

Zafar, One of the things I keep seeing below is you referring to the operators perspective. So - as someone who actually is from an operator - and has done substantial testing of the proposed solution let me give you the perspective of an operator. Firstly - as an operator - on the table mapp