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

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 7 Sep 2019 16:17:12 +0000

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 NOT on debating the solution.

Furthermore, during Spring WG meeting, Bob (6man chair), said:

[Bob Hinden] As 6man co-chair, would like to understand whether SPRING is interested in this (CRH) work. A clear message would be useful to ensure that 6man spends time usefully [https://etherpad.ietf.org/p/notes-ietf-105-spring].

  *   You ignored the chair’s direction.
  *   You added 6man WG for some unknown reasons.

Since you added 6man to this Spring discussion on the “requirements”, among many other things, the two WGs witnessed:

  *   Spring chairs and AD were repeatedly flamed. They had to defend [https://mailarchive.ietf.org/arch/msg/spring/ZFm_bQP1-C2f9xJuXtvEd9mLoxU]
  *   6man AD/ chairs had to defend, e.g., https://mailarchive.ietf.org/arch/msg/spring/zfr-dCuSHSJRjE2NkJbfjuWoCi4.
  *   An atmosphere that the Spring and 6man are disconnected was created.
  *   Heated discussions (that are not on the table).
  *   Etc.

Not to mention, many lost their sleep, long weekend, hair, deadlines; gained blood pressure/ weight, etc. ;-)

Unfortunately, there is a trend. The same has been tried against SRv6, again and again.

  *   Without success.
  *   Huawei has deployed.
  *   Cisco has deployed.
  *   Several operators have reported significant commercial traffic at linerate forwarding.
  *   Linux and FD.IO open-source stacks are available and have been used in deployments.
  *   Several interoperability tests have been reported.
  *   Numerous SP’s are clearly asking SRv6 in RFP, and the deployment prospect in 2020 and 2021 is significant.

In summary,

Can you please follow the directions set by the chairs and stop creating email threads?

This is not how we are supposed to promote technologies at IETF.

Thanks

Regards ... Zafar

From: Ron Bonica <[email-masked]>
Date: Friday, September 6, 2019 at 1:34 AM
To: "Zafar Ali (zali)" <[email-masked]>, Shraddha Hegde <[email-masked]>, Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [spring] Beyond SRv6.

Zafar,

Your memory is selective. In the SPRING session, many people argued that “SRv6 was nearly complete and we didn’t need another solution”. But I don’t remember anybody arguing against the technical merits of SRv6+.

If you can make a technical argument against SRv6+, I encourage you to do so. I look forward to a gentlemanly exchange.

                                                                                                         Ron

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Friday, September 6, 2019 12:53 AM
To: Shraddha Hegde <[email-masked]>; Ron Bonica <[email-masked]>; Rob Shakir <[email-masked]>; SPRING WG List <[email-masked]>; [email-masked]
Cc: Zafar Ali (zali) <[email-masked]>
Subject: Re: [spring] Beyond SRv6.

<snip>
>SRv6+ is definitely a better proposal in terms
>  1.Adherence to IPv6 Architecture
>  2.Efficient encoding
>  3.Operational simplicity
>
>   There hasn't been a single mail denying the above advantages of 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 (https://mailarchive.ietf.org/arch/msg/spring/6bdX_gb47uFYnd6ytwFLPYxXCYo).

Yes, indeed Ron presented the proposal to every workgroup possible in Montreal, only to find no interest from anyone.
I would advise you to read that silence differently. 😉

<snip>

---

From: Andrew Alston <[email-masked]>
Date: Sat, 7 Sep 2019 16:42:25 +0000

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 drafts.  Can I ask when we will get an indication of this?  Since unless we are reading this wrong – it is a *vast* amount of space – and until such time as we know that – it is not possible to put the policy change proposals before the RIR’s without any more than an estimate based on our interpretations.  While I’m quite happy to go ahead with others to propose policies in the RIR space to get the space allocation proposals changed to meet the requirements of this document – I would rather do this being able to state clearly in the policy where the numbers come from.

As of right now – you are sitting there pointing at problems – that’s ok – others have shown problems in what you have put forward.  We will however respond to each of your issues – and that is more than I can say is happening right now from the SRv6 NP fraternity.  I have asked multiple times regarding the change in address semantics as defined in RFC4291 – I have zero reply on this. I have raised the issue of inflation of IGP – the only answer I have had is to renumbering my network (which in my book equates to interference of already existent deployments – please see the spring charter on this).  

I have also stated quite categorically – that I do not wish to see the work on SRv6 stopped – on the contrary – I believe that two alternatives make sense – I believe in operator choice – and indeed – I point to the fact that I explicitly proposed that we work together on an inter-op draft and was explicitly told that there was no interest in this from the authors of these drafts.   

The chairs also explicitly asked why anything we necessary beyond SRH – and when you turn and attack based on lack of justification – I have yet to see a single justification for similar in the uSID draft – so – lets be a little consistent here.

I also point out – that I and others HAVE stated why we need something more – the overhead of SRv6 for my network – and many others – is simply untenable.  uSID does not solve that problem without introducing a whole RANGE of other issues. 

So – lets now put this simply

a.) CRH/SRv6+ does not redefine the IPv6 address semantics – SRv6 NP does – uSID does again (in a way that is incompatible with SRv6 NP I might add)
b.) CRH/SRv6+ does not require the (massive) overhead that SRv6 imposes
c.) CRH/SRv6+ does not do header insertion or header removal in violation of a standard that already has consensus from the community – SRv6 NP does
d.) ISIS extensions for CRH do not propose to cater for header insertions or header removals – the SRv6 draft-ietf-lsr-isis-srv6-extensions explicitly does
e.) CRH/SRv6+ does not collapse the network routing function, the programming function and the addressing function all into the same thing – SRv6 does – creating in my view significant complexity and operational headaches
f.) When asked about binding SID’s – we stated we could support each and if given the use case we would – though we do point out that because of the overhead savings on traditional SRv6 we believe we can demonstrate that this may not be necessary – we are prepared to do it.  On the contrary – I am still yet to understand how inter-domain operation of SRv6 will actually function

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 both the semantics of addresses and issues like header insertion and removal – just because you ignored them and wrote the code we are now meant to rubber stamp it?  While at the same time – instead of working on resolving the issues that have been raised here time and again – you continue to fight to squash something that multiple people have said should go ahead?

Andrew

From: spring <[email-masked]> on behalf of "Zafar Ali (zali)" <[email-masked]>
Date: Saturday, 7 September 2019 at 19:17
To: Ron Bonica <[email-masked]>, Shraddha Hegde <[email-masked]>, Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>
Cc: "Zafar Ali (zali)" <[email-masked]>
Subject: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Ron, 

 

• You ignored the chair’s direction. 
• You added 6man WG for some unknown reasons. 

• Spring chairs and AD were repeatedly flamed. They had to defend [https://mailarchive.ietf.org/arch/msg/spring/ZFm_bQP1-C2f9xJuXtvEd9mLoxU]
• 6man AD/ chairs had to defend, e.g., https://mailarchive.ietf.org/arch/msg/spring/zfr-dCuSHSJRjE2NkJbfjuWoCi4.
• An atmosphere that the Spring and 6man are disconnected was created. 
• Heated discussions (that are not on the table). 
• Etc. 

 
• Without success.
• Huawei has deployed.
• Cisco has deployed.
• Several operators have reported significant commercial traffic at linerate forwarding.
• Linux and FD.IO open-source stacks are available and have been used in deployments.
• Several interoperability tests have been reported.
• Numerous SP’s are clearly asking SRv6 in RFP, and the deployment prospect in 2020 and 2021 is significant.
 
In summary, 

Thanks 
 
Regards ... Zafar 

Zafar,

 
                                                                                                         Ron

 
 
<snip> 

 
 
<snip>

---

From: Sander Steffann <[email-masked]>
Date: Sat, 7 Sep 2019 18:56:49 +0200

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 both the semantics of addresses and issues like header insertion and removal – just because you ignored them and wrote the code we are now meant to rubber stamp it?

Rough consensus and running code... But we work by rough consensus.
Running code that explicitly goes against consensus is no IETF standard at al.

Cheers,
Sander

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Sat, 7 Sep 2019 17:10:02 +0000

Hi,

Please see in-line.

Thanks

Regards … Zafar

From: Sander Steffann <[email-masked]>
Date: Saturday, September 7, 2019 at 12:57 PM
To: Andrew Alston <[email-masked]>
Cc: "Zafar Ali (zali)" <[email-masked]>, Ron Bonica <[email-masked]>, Shraddha Hegde <[email-masked]>, Rob Shakir <[email-masked]>, SPRING WG List <[email-masked]>
Subject: Re: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Hi,

[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 rigorous IETF process (some may say much more rigorous than typically done at IETF).

---

From: Sander Steffann <[email-masked]>
Date: Sat, 7 Sep 2019 19:22:06 +0200

> [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 industr…

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: Fernando Gont <[email-masked]>
Date: Sun, 8 Sep 2019 00:49:18 +0300

On 7/9/19 19:17, Zafar Ali (zali) wrote:

> 
>   * Spring chairs and AD were repeatedly flamed. They had to defend
>     [https://mailarchive.ietf.org/arch/msg/spring/ZFm_bQP1-C2f9xJuXtvEd9mLoxU]
>   * 6man AD/ chairs had to defend,
>     e.g., https://mailarchive.ietf.org/arch/msg/spring/zfr-dCuSHSJRjE2NkJbfjuWoCi4.

FWIW, I have no idea whatsoever what you are talking about. Nobody was
"flamed". You quote a message from Suresh, in which I asked how the IESG
handles these things.

I did make comments to Ole and Suresh, because they are co-chair and
responsible AD for 6man, and I think their comments to disregard the
statement in RFC8200 as if it wasn't the result of technical arguments
is both wrong and unfair to the wg for which they are responsible.
(Besides the fact that it represents *IETF* consensus).

This was noted by others:

* https://mailarchive.ietf.org/arch/msg/ipv6/9dfgDhjuMIvHfSAXg2bcFAa9q6s
* https://mailarchive.ietf.org/arch/msg/ipv6/5KvaCMhsq819wcHxTkF7TpBdzLg
* https://mailarchive.ietf.org/arch/msg/ipv6/CTMqxFA2Goa6e4Fp5OFYJx92eHQ
* https://mailarchive.ietf.org/arch/msg/ipv6/Rfd2RmNJ6Q1OikAJT5llf3BdSZg

Given the past history with this topic (see:
<https://mailarchive.ietf.org/arch/msg/ietf/j1O11x4ICMUWGJmzlJfCx0y0-c8>
and
<https://mailarchive.ietf.org/arch/msg/ietf/KGfHVQ6Hazb5NJkaGxG8WL3kYS0>),
I think the above is not acceptable.

And since they are in leadership positions, it's our responsibility to
note these things when they happen.

My question to the spring people obviously came from that background. I
realize that the spring co-*chairs* might not be aware about the history
of EH insertion within 6man. I do think that the RTG *ADs* should, since
part of the discussion of EH insertion happened during IETC LC and IESG
review of rfc2460bis.

I'd note that, according to our charter:
The 6man working group is responsible for the maintenance, upkeep, and
advancement of the IPv6 protocol specifications and addressing
architecture. It is not chartered to develop major changes or additions
to the IPv6 specifications.

Allowing EH insertion seems to me like a major change or addition to IPv6.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Sep 2019 23:42:30 +0300

On 7/9/19 20:10, Zafar Ali (zali) wrote:
[....]
> [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
> rigorous IETF process (some may say much more rigorous than typically
> done at IETF).  

The rigurous IETF process says that you cannot do EH insertion. And you
are insisting in circumventing that process.

Thanks,

---

From: James Guichard <[email-masked]>
Date: Tue, 10 Sep 2019 12:59:28 +0000

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]> On Behalf Of Sander Steffann
Sent: Saturday, September 07, 2019 1:22 PM
To: 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.)

[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://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>. 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).

Cheers,
Sander

---

From: Ron Bonica <[email-masked]>
Date: Tue, 10 Sep 2019 13:30:15 +0000

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

Cheers,
Sander

---

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

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 not

As one of your customers, I never claim that thing.

--satoru

2019/09/10 22:30、Ron Bonica <rbonica=[email-masked]>のメール:

> 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
>  
> New work would overtax the WG
> A new solution would confuse the market place
>  
> The marketplace doesn’t need to be protected from new solutions. Those who claim that it does may want to explain why.
>  
>                                                                          Ron
>  
>  
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring