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.

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

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] Binding SID in SRv6/SRv6 (was: Beyond SRv6)

I think the key point here is that BSID is not only as a means of “a shorthand that can be used to represent a list of SIDs”. Please see draft-ietf-spring-segment-routing-policy for the use-cases for BSID (including the one pointed by Jeff). Besides BSID, we also have TI-LFA

Re: [spring] Beyond SRv6.

Hi Ron, Please see in-line. Thanks Regards … Zafar From: Ron Bonica Date: Friday, September 6, 2019 at 1:57 AM To: "Zafar Ali (zali)" , Srihari Sangli , Tarek Saad , Rob Shakir , SPRING WG List , "6...@ietf.org" <6...@ietf.org> Subject: RE: [spring] Beyond SRv6. Inline….. Juniper

Re: [spring] Beyond SRv6.

Ali, Nothing so complicated is required. At most, PING and TRACEROUTE with RFC 5837 extensions. Ron Juniper Business Use Only From: Zafar Ali (zali) Sent: Friday, September 6, 2019 2:18 AM To: Ron Bonica ; Srihari Sangli ;

Re: [spring] Beyond SRv6.

> This is absolutely false!   > Have you forgotten the very strong arguments against it at the Spring session > in Montreal and the various emails on the list that echoed them  > Not to mention comments from Robert R >

Re: [spring] Beyond SRv6.

Hi Ron, MPLS tool kit was created as IP tool kit (ICMP) was not sufficient to debug an MPLS subsystem. By bringing in the “label mapping table” in IPv6 network, you have inherited the same problem industry has solved for MPLS OAM during the last ~20 years. Thanks Regards … Zafar From: Ron

Re: [spring] Beyond SRv6.

> Nothing so complicated is required. At most, PING and TRACEROUTE with RFC > 5837 extensions. Are there any vendors actually implementing RFC 5837? Ivan Pepelnjak commented "However, it looks like nobody implemented it in almost five years since it was published." at

Re: [spring] Beyond SRv6.

Hi Steinar, I am glad you asked. I am not aware of any implementation of RFC 5837. Even if it is implemented, it never talks about providing information from a distributed “local label mapping table”, as defined by the CRH. Thanks Regards … Zafar From: ipv6 on behalf of "sth...@nethelp.no"

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

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.

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

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] 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

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.

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

[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

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

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

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

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

> > 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] 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] 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

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

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:

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

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

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 >

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

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

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

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

[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

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

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

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 >

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

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

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

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: [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

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

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] 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;

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.

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:

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] 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

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

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

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] 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