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

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 11 Sep 2019 04:27:26 +0000

<snip>

Hi, Robert:

But the concept of SRv6+ is more clear than the SRv6(topology/service instruction separation; different instruction carried in different IPv6 EH).

Hi Aijun,

Can you please various thread to gauge the complexity, incompleteness and why CRH (aka SRv6+) makes no sense, e.g.,:

  *   Countless responses from Robert, includinghttps://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE
  *   Many responses like https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4
  *   Many responses from Dirk, including https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM
  *   Excellent points from Dan https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4.
  *   Many reasons like https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ

Hope it helps,

Thanks

Regards … Zafar

<snip>

---

From: Andrew Alston <[email-masked]>
Date: Wed, 11 Sep 2019 05:04:16 +0000

Ok, so couple of things.

I really think we need to clearly and totally divorce the comments on this list from those around SRH – since – there seems to be this kind of bizarre conflating of two issues, and while it’s a nice piece of obfuscation – let’s be clear on a number of things.

  1.  Almost every  objection on this list that I have seen has related directly to the NP and uSID drafts – not towards the SRH draft which does not sit within this working group.  The primary problem I see with the SRH draft is around overhead – and well – if people wish to live with that level of overhead – so be it – but, that does not relate to the complexity, the violations of RFC8200 and the wholesale re-definition of the address semantics as defined by RFC4291 that have been objected to here – those issues are directly related to the NP and uSID drafts.  Let’s be clear on that.
  2.  The constant citing of a marketing document – where almost everything in there is related to the use of SRv6 in the context of the SRH – again – not in this working group – with little evidence or citation of use of the NP draft or the uSID drafts which are what we sound be discussing here – is, in my view, really stretching for support – through an obfuscation of items that while related are not the same thing

Now, there is also an argument I have seen that you should not have two things that solve the same problem.  So, lets talk about the CRH for a second.  CRH does not address the same issues that the NP draft does – it addresses an insane and inescapable overhead issue.  In the process of doing that, it provides, in my view, a cleaner version of the functionality of that contained in the network programming draft and the uSID draft, without header insertion and without the burning of absolutely insane amounts of address space.  So again – let’s not conflate issues here.

Now – I would ask this, and I have asked the questions before and not seen them addressed – if they have been – I would be more than happy to be corrected and be pointed to the emails that address these things

  1.  Can someone explain how with the use of NP proper aggregation is going to work
  2.  Can someone please – as per the request made by the chairs in Montreal – supply an indication of the address space burn that is required – both in terms of the uSID draft and the NP draft
  3.  Can the authors please explain how either of these drafts is proposed to work in either an inter-asn or inter-igp area scenario – or – is this explicitly and unequivocally designed to work only within a single domain – and if that is the case – I’d be happy to explain how this would work with CRH – and why there is an additional requirement for CRH beyond the removal of the overhead
  4.  In the case of uSID – can we get an explanation of how it is compatible with the network programming draft outside of end point programming – since the way I see it – if you’re shifting bits to effectively perform “routing by NAT” – you’re throwing away the locator bits as defined in the network programming draft.  If the answer to this is to retain the entire SID list – then the overhead reduction disappears – and at which point, please can someone explain to me why you would run uSID at all if you are doing this.
  5.  Since we have had constant references to multiple platforms supporting this – can we get a list of actual vendors and hardware that support the NP and uSID drafts in production today – not SRH – NP and uSID – and inter-op tests between these platforms.  Let’s separate the issues here.
I will also say – I do NOT oppose work continuing on SRH and SRv6 – never have – never will.  I also do not oppose work continuing on either the NP or uSID drafts – provided the issues that have been raised – time and again on this list are addressed.  However, I will also state that I do not believe that CRH performs the same function as the NP draft, what it does is include the functionality involved in the NP draft, while solving an overhead issue – and on that basis alone, outside of many other reasons, I believe that work on it should continue.

Over the last few days reading emails on this list – I fear a situation where both sides (and I include myself on this), are feeling the need to attack each other – and block the work on “opposing” drafts.  Now, I can easily see how this could arise – but – I’ll also say that I don’t think its in the interests of the industry, or the operators, or well, anyone.  I would far rather see a situation where we work towards a productive solution – let work continue on all of this, and then let the industry decide which they want to use, and indeed, work towards a productive solution where we have some interoperability.  And yes, as was alluded to, I did raise the possibility of an inter-op draft to facilitate forward movement here, and I had only one vendor out of all the vendors I approached actually indicate opposition to this, so I would ask now directly on list, can we work towards a situation where instead of all blocking each other – work continues and we find a way to play nice, and indeed, inter-operate?  I really fear that the alternative is that this fight drags on forever, and in the mean time, vendors and operators alike continue to develop and deploy outside of the standardization – and every day that continues – we move further away from being able to find a sane way to inter-operate.

There is a phrase that I have heard – and perhaps it applies here – perhaps we need to put our guns down – and find a way to in which we can move forward that while it probably will not satisfy everyone, will be in the interests of the market in general by avoiding a total standoff.

Just my thoughts

Andrew

From: Zafar Ali (zali) <[email-masked]>
Sent: Wednesday, 11 September 2019 07:27
To: Aijun Wang <[email-masked]>; 'Robert Raszuk' <[email-masked]>; 'Sander Steffann' <[email-masked]>
Cc: '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]>; 'Voyer, Daniel' <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: 答复: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

<snip>

Hi, Robert:

Hi Aijun,

  *   Countless responses from Robert, includinghttps://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE<https://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE>
  *   Many responses like https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4<https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4>
  *   Many responses from Dirk, including https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM<https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM>
  *   Excellent points from Dan https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4<https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4>.
  *   Many reasons like https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ<https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ>

Hope it helps,

Thanks

Regards … Zafar

<snip>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 11 Sep 2019 10:10:00 +0200

Hi Andrew,

> And yes, as was alluded to, I did raise the possibility of an inter-op
draft to facilitate
> forward movement here, and I had only one vendor out of all the vendors I
approached
> actually indicate opposition to this, so I would ask now directly on
list, can we work
> towards a situation where instead of all blocking each other – work
continues and we
> find a way to play nice, and indeed, inter-operate?

If so many vendors you approached indicated no opposition to work on
interop draft and solution where is it ?

Note that each piece wire or fiber has (at least) two ends. So if the SRv6+
side takes the burden of translation to and from new control plane
extensions of SRv6+ and new data plane encoding SRv6+ and if this is
clearly spelled out in the draft then perhaps you would see much easier or
say different acceptance or resistance level in IETF for SRv6+ ?

If I were to suggest strategy to introduce such proposal like SRv6+ I would
start with that then later focus on number of protocol extensions drafts.

Bottom line is that I seriously doubt that any vendor would support all
three: SR-MPLS, SRv6 & SRv6+ just to make few customers happy. And that is
regardless on the business case. It is just realistically too expensive to
develop and too support.

- - -

And as proposed before not only by myself but others what is functionally
missing if you were to use SR-MPLS with IP encap between segment nodes as
compared to SRv6+ ? If SRv6+ would find a cool and smart way to propose
stateless compression of  IPv6 address into SID it would perhaps had some
value, but it does not. It takes flat 16 or 32 bits and maps it to IPv6 ..
in exactly same way as you map MPLS label based SID to an IP address.

And for those who do not like to see MPLS even at service level they should
stop running L3VPNs over MPLS or over IP too. Note that SRv6+ still
proposes to use MPLS label in PPSI for VPN demux encoding see section 7 of
https://tools.ietf.org/html/draft-ssangli-idr-bgp-vpn-srv6-plus-02#section-7

Thx,
R.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 11 Sep 2019 12:19:00 +0200

Hi Andrew,

> There is a phrase that I have heard – and perhaps it applies here – perhaps we need to put our guns down – and find a way to in which we can move forward that while it probably will not satisfy eve…

Thank you for your wise words. I have also gotten carried away in this discussion. I'll take a step back and think more carefully before I post. I just saw Robert's reply and I hope that in time he'll do the same. Guns down...

Cheers,
Sander

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Wed, 11 Sep 2019 13:03:14 +0000

+1,

Thanks

Regards … Zafar

From: Sander Steffann <[email-masked]>
Date: Wednesday, September 11, 2019 at 6:26 AM
To: Andrew Alston <[email-masked]>
Cc: "Zafar Ali (zali)" <[email-masked]>, Aijun Wang <[email-masked]>, Robert Raszuk <[email-masked]>, Ron Bonica <rbonica=[email-masked]>, SPRING WG List <[email-masked]>, James Guichard <[email-masked]>, Shraddha Hegde <[email-masked]>, Rob Shakir <[email-masked]>, "Voyer, Daniel" <[email-masked]>
Subject: Re: 答复: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Hi Andrew,

Cheers,
Sander

---

From: Ron Bonica <[email-masked]>
Date: Wed, 11 Sep 2019 13:23:35 +0000

Finally, something we can agree on !!

Juniper Business Use Only
From: Zafar Ali (zali) <[email-masked]>
Sent: Wednesday, September 11, 2019 9:03 AM
To: Sander Steffann <[email-masked]>; Andrew Alston <[email-masked]>
Cc: Aijun Wang <[email-masked]>; Robert Raszuk <[email-masked]>; Ron Bonica <[email-masked]>; SPRING WG List <[email-masked]>; James Guichard <[email-masked]>; Shraddha Hegde <[email-masked]>; Rob Shakir <[email-masked]>; Voyer, Daniel <[email-masked]>; Zafar Ali (zali) <[email-masked]>
Subject: Re: 答复: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

+1,

Thanks

Regards … Zafar

From: Sander Steffann <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, September 11, 2019 at 6:26 AM
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: "Zafar Ali (zali)" <[email-masked]<mailto:[email-masked]>>, Aijun Wang <[email-masked]<mailto:[email-masked]>>, Robert Raszuk <[email-masked]<mailto:[email-masked]>>, Ron Bonica <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>, SPRING WG List <[email-masked]<mailto:[email-masked]>>, James Guichard <[email-masked]<mailto:[email-masked]>>, Shraddha Hegde <[email-masked]<mailto:[email-masked]>>, Rob Shakir <[email-masked]<mailto:[email-masked]>>, "Voyer, Daniel" <[email-masked]<mailto:[email-masked]>>
Subject: Re: 答复: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Hi Andrew,

Cheers,
Sander

---

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

Andrew,

I would like to amplify something that you said. SRv6 and SRv6+ are both designed to operate within limited domains. Beyond competing for market share, the existence of one does not threaten the existence of the other.

I do not oppose the progressing of the SRv6 drafts (while, as a WG participant, I do reserve the right to comment on them). I would hope that the proponents of SRv6 would extend the same courtesy to SRv6+.

                                                                                 Ron

Juniper Business Use Only
From: Andrew Alston <[email-masked]>
Sent: Wednesday, September 11, 2019 1:04 AM
To: Zafar Ali (zali) <[email-masked]>; Aijun Wang <[email-masked]>; 'Robert Raszuk' <[email-masked]>; 'Sander Steffann' <[email-masked]>
Cc: Ron Bonica <[email-masked]>; 'SPRING WG List' <[email-masked]>; 'James Guichard' <[email-masked]>; Shraddha Hegde <[email-masked]>; 'Rob Shakir' <[email-masked]>; 'Voyer, Daniel' <[email-masked]>
Subject: RE: 答复: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

Ok, so couple of things.

Just my thoughts

Andrew

From: Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, 11 September 2019 07:27
To: Aijun Wang <[email-masked]<mailto:[email-masked]>>; 'Robert Raszuk' <[email-masked]<mailto:[email-masked]>>; 'Sander Steffann' <[email-masked]<mailto:[email-masked]>>
Cc: 'Ron Bonica' <rbonica=[email-masked]<mailto:rbonica=[email-masked]>>; 'SPRING WG List' <[email-masked]<mailto:[email-masked]>>; Andrew Alston <[email-masked]<mailto:[email-masked]>>; 'James Guichard' <[email-masked]<mailto:[email-masked]>>; 'Shraddha Hegde' <[email-masked]<mailto:[email-masked]>>; 'Rob Shakir' <[email-masked]<mailto:[email-masked]>>; 'Voyer, Daniel' <[email-masked]<mailto:[email-masked]>>; Zafar Ali (zali) <[email-masked]<mailto:[email-masked]>>
Subject: Re: 答复: [spring] Going back to the original question for the Spring WG (was: Re: Beyond SRv6.)

<snip>

Hi, Robert:

Hi Aijun,

  *   Countless responses from Robert, includinghttps://mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/_V8dsQOeRTuK2r7Lfi77bgICqhE__;!8WoA6RjC81c!V2JuloFFP6eIofRow4y1fvxLhyRD8wFrI8LPfA3SJhwUT7MxoQAfIXEAT3xWkYUH$>
  *   Many responses like https://mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/wFDK_Be7lEt4s191m61WdUOEzL4__;!8WoA6RjC81c!V2JuloFFP6eIofRow4y1fvxLhyRD8wFrI8LPfA3SJhwUT7MxoQAfIXEAT46E0ITc$>
  *   Many responses from Dirk, including https://mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/6Bm4nN5ah8rFb7VutexK30kRUPM__;!8WoA6RjC81c!V2JuloFFP6eIofRow4y1fvxLhyRD8wFrI8LPfA3SJhwUT7MxoQAfIXEAT36r5m4U$>
  *   Excellent points from Dan https://mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/OB1l41EhhUu8x8XEnKaBTdczDj4__;!8WoA6RjC81c!V2JuloFFP6eIofRow4y1fvxLhyRD8wFrI8LPfA3SJhwUT7MxoQAfIXEAT_KV6wy7$>.
  *   Many reasons like https://mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/D7IFJakb5Ew2iMXUfvf1wub7arQ__;!8WoA6RjC81c!V2JuloFFP6eIofRow4y1fvxLhyRD8wFrI8LPfA3SJhwUT7MxoQAfIXEATwriZDG5$>

Hope it helps,

Thanks

Regards … Zafar

<snip>